3. What’s New in 7.7.0
This section describes what’s new in RTI® Security Plugins 7.7.0, compared to 7.6.0.
Security Plugins 7.7.0 is the first production release in the 7.7 long-term support (LTS) series. It is built upon and combines all of the features in releases 7.4.0, 7.5.0, and 7.6.0. See Connext Versions and Lifecycle for more information on RTI’s software release model.
For what’s new in other products in the Connext suite, see those products’ release notes on the RTI Community Portal or in your installation. Or start with RTI Connext What’s New for a launchpad to all products.
Note
For backward compatibility information between 7.7.0 and previous releases, see the Migration Guide on the RTI Community Portal.
3.1. Distributed secure logging for the Lightweight Security Plugins
Lightweight DomainParticipants can now distribute security logging
information over DDS. You can subscribe to this data via the new
DDS:Security:PSK:LogTopic Builtin Secure Logging Topic. You can
subscribe to the new builtin Topic from DomainParticipants that
are using either the Lightweight Builtin Security Plugins or the
Builtin Security Plugins in a configuration that can interoperate
with Lightweight security. Note that Lightweight DomainParticipants
remain unable to subscribe to the DDS:Security:LogTopicV2 logging Topic
because it is protected at the Topic level.
See Security Events and Logging for more information.
3.2. Upgrade to wolfSSL 5.8.2
The Security Plugins for wolfSSL are now based on wolfSSL version 5.8.2.
For release 7.7.0, the Security Plugins are API-compatible with wolfSSL version 5.8.2, not with earlier versions. Note that the Security Plugins 7.7.0 have only been tested by RTI using wolfSSL 5.8.2.
In addition to the upgraded version of wolfSSL, the Security Plugins for wolfSSL now support partial chains. The certificate of the Identity Certificate Authority no longer has to be self-signed; intermediate Certificate Authorities are also supported.
3.4. Faster repairs of lost samples due to shorter default heartbeat periods for Secure Key Exchange Builtin Topic Writer
The out-of-the-box default values for the
SecureVolatileWriter::heartbeat_period, fast_heartbeat_period,
and late_joiner_heartbeat_period for the Secure Key Exchange Builtin
Topic DataWriter have been changed to make them faster.
SecureVolatileWriter::max_heartbeat_retries has also been changed to
maintain the same amount of time it takes before the Secure Key Exchange
Builtin Topic DataReader is considered inactive. Finally,
SecureVolatileWriter::heartbeats_per_max_samples increased so the
heartbeats are sent with DATA packets more often. The changes are as
follows:
DataWriter Kind |
heartbeat_period |
fast_heartbeat_period |
late_joiner_heartbeat_period |
max_heartbeat_retries |
heartbeats_per_max_samples |
|---|---|---|---|---|---|
Secure Volatile DataWriter |
1 sec → 200 ms |
250 ms → 200 ms |
1 sec → 200 ms |
800 → 1,000 |
1 → 100,000,000 |
The new defaults speed up the repair process when a symmetric key sample has been lost. Faster repairs mean that communication can begin faster. With faster heartbeat periods, you may notice an increase in network traffic because more heartbeats and acknowledgments are sent. You may choose to slow down the defaults if your network is not lossy, and you can wait longer for samples to be repaired if they are lost.
The max_heartbeat_retries QoS value was also changed. It was changed from
800 to 1000 so that the time it takes before the Secure Key Exchange
Builtin Topic DataWriter considers the Secure Key Exchange Builtin
Topic DataReader inactive remains the same as in previous releases
(200 seconds).
3.5. Improved network utilization and memory footprint for intraparticipant communication
The Secure Key Exchange Channel is used to exchange keys between DomainParticipants. In previous releases, it was also used to exchange keys within the same DomainParticipant. The intraparticipant key exchange is not necessary because a DomainParticipant always knows its own keys. This release improves network utilization and memory footprint by removing the intraparticipant key exchange.
If you use the Security Plugins SDK, please see the Security Plugins Interface (SPI) Notes section of the SDK documentation for details on the interface changes that were required for this improvement.
3.6. Simplified configuration when enabling origin authentication for message protection
Previous releases required you to set the
cryptography.max_receiver_specific_macs property in order to use
WITH_ORIGIN_AUTHENTICATION in any of the Governance Document
protection_kind fields. This requirement resulted in one or more of
the following:
Lack of support for an unbounded number of MACs. The transport message_size_max (which could be very small in systems with a small maximum transmission unit (MTU)) limited the maximum potential value of
cryptography.max_receiver_specific_macsdue to the need to send all applicable destinations’ MACs associated with an RTPS message.Security degradation when the configured limit was exceeded for a given RTPS message.
Potential waste of resources (memory and inefficient usage of the network MTU) because of pre-allocating all the keys necessary to support the configured limit.
This release removes this requirement for the rtps_protection_kind.
If your rtps_protection_kind contains WITH_ORIGIN_AUTHENTICATION
and no other protection_kind contains
WITH_ORIGIN_AUTHENTICATION, then you no longer need to set
cryptography.max_receiver_specific_macs.
For more information, see Origin Authentication Protection Implications in the RTI Security Plugins User’s Manual.
3.7. Support for configuring flags used to load Security Plugins dynamic library
If you are linking the Security Plugins library dynamically, you can now configure the flags used to load the Security Plugins library. This option is supported on Linux, macOS, and QNX systems. It is also supported on Android and VxWorks systems when using RTP mode. It is not supported on Windows systems.
In addition to the com.rti.serv.secure.library and
com.rti.serv.secure.create_function properties, now you can
configure the com.rti.serv.secure.library_flags property. This
property takes an integer representing the flags passed to the
dlopen() function. You must look for the architecture-specific
integer value for each flag you want to configure, and calculate the
final property value as the OR operation of all these flags. If the
com.rti.serv.secure.library_flags property is not set, the default
flags are:
RTLD_NOW | RTLD_DEEPBIND
For example, on Linux systems, these flags translate to 0x00002 and
0x00008, resulting in a final value of 0x0000A; not configuring
the com.rti.serv.secure.library_flags property has the same behavior
as setting the property value to 0x0000A.
This feature is useful if you need to customize how to load the Security Plugins dynamic library. For example, you may need to customize the flags if you want to enable Address Sanitizer (ASan) in applications using the Security Plugins. Enabling modern versions of ASan in combination with the Security Plugins will result in the following error (if the default flags are used):
WAR==683==You are trying to dlopen a libnddssecurityd.so shared library with RTLD_DEEPBIND flag which is incompatible with sanitizer runtime (see https://github.com/google/sanitizers/issues/611 for details). If you want to run libnddssecurityd.so library under sanitizers please remove RTLD_DEEPBIND from dlopen flags.
This error is due to an Address Sanitizer bug. Continuing with our Linux
example, you can work around the error by setting the
com.rti.serv.secure.library_flags property to 0x00002
(RTLD_NOW). You should only do this if you don’t intend to use the
Python API, or if you use the Python API but are sure your Python
version doesn’t have a builtin OpenSSL. For more information, see
[Major] Possible crash when using Python API due to collision with OpenSSL symbols when using certain Python releases.
3.8. Deprecations and Removals
Deprecated means that the item is still supported in this release, but will be removed in a future release. Removed means that the item is discontinued or no longer supported.
Any deprecations or removals noted in RTI’s documentation serve as notice under the Real-Time Innovations, Inc., Maintenance Policy #4220 and/or any other agreements by and between RTI and customer regarding maintenance and support of RTI’s software. RTI’s current standard terms and support and maintenance policies are available at https://www.rti.com/terms.
3.8.1. Authentication properties deprecated
As mentioned in Alternative Certificate Authorities configuration easier by using data directly, the authentication.alternative_ca_files
and access_control.alternative_permissions_authority_files properties
are now deprecated.
3.8.2. Removed support for AES-192-GCM symmetric cipher algorithm
Following the deprecation of AES-192-GCM in release 7.3.0, release 7.7.0 now completely removes this cryptographic algorithm from the list of available symmetric cipher algorithms.
If you are still using AES-192-GCM in your system, please transition to AES-256-GCM or AES-128-GCM. For more information about symmetric cipher algorithms, see Algorithms Involved in Protecting Secure Entities Traffic in the RTI Security Plugins User’s Manual.
3.8.3. Removal of the deprecated SecurityPluginSuite_create entry point
As described in the Migration Guide
here,
the Security Plugins have removed the SecurityPluginSuite_create entry point.
3.9. Third-Party Software Changes
The following third-party software used by Security Plugins has been upgraded:
Third-Party Software |
Old Version |
New Version |
|---|---|---|
OpenSSL |
3.5.1 |
3.5.5 |
For information on third-party software used by Connext products, see the “3rdPartySoftware” documents in your installation: <NDDSHOME>/doc/manuals/connext_dds_professional/release_notes_3rdparty.