6.4. What’s Fixed in 7.0.0 — RTI Security Plugins Release Notes 7.2.0 documentation

6.4.1. Fixes Related to Discovery and Authentication

6.4.1.1. Reader incorrectly lost liveliness with writer when using enable_liveliness_protection

A DataReader incorrectly reported that a DataWriter lost liveliness at the max_liveliness_loss_detection_period when using enable_liveliness_protection, if the DataWriter’s (lease_duration)/(assertions_per_lease_duration) was greater than the max_liveliness_loss_detection_period—even if the full lease_duration had not passed. This problem has been resolved.

[RTI Issue ID SEC-1630]

6.4.1.2. Key agreement did not use ephemeral key pairs as required by DDS Security specification

The DDS Security 1.1 specification states that dh/ecdh key pairs used for Key Agreement should be used only once (i.e., the key should be ephemeral). Previous Security Plugins releases were not compliant with this.

As a result, every DomainParticipant reused the same Key Agreement public/private key pair for performing Key Establishment with other DomainParticipants. Note that recreating the DomainParticipant resulted in new keys. The keys were recreated upon DomainParticipant recreation, not upon every DomainParticipant-to-DomainParticipant Key Establishment process.

This non-compliant behavior increased the impact of a hypothetical successful attack where the attacker already took over a DomainParticipant’s dh/ecdh keys:

In previous releases, taking over a DomainParticipant’s temporary dh/ecdh private key (which is reused during the DomainParticipant’s lifetime) would have resulted in being able to access any communications involving this DomainParticipant (with any other DomainParticipant).
Starting with this release (7.0.0), the impact of taking over a DomainParticipant’s temporary dh/ecdh private key (which is now only used during one Key Establishment process with a specific DomainParticipant) is reduced. Now it will result in only being able to access any communications involving the two DomainParticipants involved in the authentication (as opposed to all communications from the compromised DomainParticipant).

[RTI Issue ID SEC-1676]

6.4.2. Fixes Related to Cryptography

6.4.2.1. Data protection kind did not protect serialized keys sent with dispose samples

If you set DataWriterQos.protocol.serialize_key_with_dispose to true, and you set the Governance document tag data_protection_kind to a value other than NONE, then the key that was serialized with a dispose sample was, incorrectly, not protected.

To protect this key, you had to set a Governance document tag, metadata_protection_kind or rtps_protection_kind, to a value other than NONE. This problem has been fixed.

The fix affects backward interoperability with Security Plugins 6.1.1 and below. Please see the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation) for details.

[RTI Issue ID SEC-627]

6.4.3. Fixes Related to Access Control

6.4.3.1. When parsing domain rules from a Permissions document, Security Plugins applied an incorrect order-of-precedence

In 6.1.1, the Security Plugins used an incorrect order-of-precedence when parsing conflicting domain rules from a Permissions document. This problem would have prevented a Connext 6.1.1 or higher application from communicating with a Connext 7.0.0 (or higher) application.

For example, in the following Permissions Document snippet, a 7.0.0 DomainParticipant on domain 12 (let’s call this DomainParticipant P1) should be allowed to exist:

<allow_rule>
   <domains>
      <id>12</id>
   </domains>
</allow_rule>
<deny_rule>
   <domains>
      <id>12</id>
   </domains>
</deny_rule>

But when another DomainParticipant, P2, discovered P1, P2 incorrectly denied P1 from communicating with it because P2 applied the deny rule instead of the allow rule.

The fix for this issue “future-proofs” compatibility between applications based on Connext 7.0.0 and higher. If you have a 6.1.1-based application that needs to communicate with a 7.0.0-based application, you will need a 6.1.1 patch; please contact RTI Support. Further information is in the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation).

This problem was one scenario within the scope of the problem described in SEC-850, which was described as fixed in Security Plugins 6.1.1 but was missing the 7.0.0-related fix described here.

[RTI Issue ID SEC-1687]

6.4.4. Fixes Related to Interoperability with Other Vendors

6.4.4.1. Could not detect participant discovery changes from DomainParticipants using non-RTI Security Plugins

If a DomainParticipant using RTI Security Plugins was communicating with more than four DomainParticipants that were using DDS Security and that were changing their QoS at any time, then there were two problems:

The following warning would have incorrectly been logged when receiving a ParticipantBuiltinTopicData sample indicating a QoS change from any DomainParticipant beyond the fourth one:
This warning was benign if it was logged upon receiving a ParticipantBuiltinTopicData sample from a DomainParticipant that was created using the RTI Security Plugins. But if the DomainParticipant was not created using a different implementation of DDS Security, then its QoS change would have gone undetected.

This problem, which only affected Security Plugins 6.0.0 and above, has been fixed.

[RTI Issue ID SEC-1639]

6.4.4.2. Incorrect key agreement algorithm sent by replier DomainParticipant

Version 1.1 of the DDS Security Specification mandates that the replier DomainParticipant must set the key agreement algorithm in the authentication handshake equal to the value received from the initiator DomainParticipant.

In previous releases, the replier DomainParticipant incorrectly set the value in the handshake to its own key agreement algorithm, when it should have used the initiator’s. This did not impact Connext Secure or Connext Micro, but it might have caused interoperability issues with other vendors. The issue has been fixed.

[RTI Issue ID SEC-1674]

6.4.5. Fixes Related to Debuggability

6.4.5.1. Debug messages not logged when Logging Plugin used Connext Builtin Logging System

If the Security Logging Plugin was configured to use the Connext Builtin Logging System, debug-level messages (DDS_LOGGING_DEBUG_LEVEL) were not logged, even if the logging.verbosity property was set to DEBUG.

This was due to a mismatch in the translation between the Logging Plugin and the Connext log levels. This problem has been resolved.

[RTI Issue ID SEC-1640]

6.4.5.2. Verbosity was not per application when Logging Plugin used Connext Builtin Logging System

For messages logged through the Connext Builtin Logging System (either directly or by the Logging Plugin), the verbosity is supposed to be per application, meaning that, if a DomainParticipant has configured the verbosity, it will update it for all DomainParticipants within the application. This did not always happen, however, when the messages came from the Logging Plugin.

When messages came from the Logging Plugin, they were filtered out twice: at the Logging Plugin level (using the verbosity that was configured for the DomainParticipant upon creation) and at the Connext level (using the verbosity specified by the last DomainParticipant created in the application). As a result, the threshold used for determining if a message should be logged or not was the lower of the two verbosity levels.

Because of this, if a second DomainParticipant specified a greater verbosity level than the first one, the verbosity of the first one was not changed, because messages were being discarded anyway at the Logging Plugin level.

Now, the Security verbosity is always per application, regardless of whether the messages come from the Logging Plugin, and regardless of whether the Logging Plugin is configured to use the Connext Builtin Logging System. The last DomainParticipant to configure the Security verbosity will apply that setting to all the DomainParticipants within the application.

[RTI Issue ID SEC-1648]

6.4.5.3. Validation of boolean properties did not treat non-boolean values as errors

In previous releases, specifying a non-boolean value was treated as not specifying any value at all, and Connext silently used the default value. This problem has been resolved. Now, specifying a non-boolean value for a boolean property will result in an error containing “is not a boolean value”, followed by entity creation failure.

[RTI Issue ID SEC-1653]

6.4.5.4. Obscure error messages when failing to verify Identity Certificate in debug libraries of Security Plugins for wolfSSL

The Security Plugins for wolfSSL logged a message similar to the following if verification of the Identity Certificate failed:

RTI_Security_CryptoLibAdapterWolfSSL_logging_cb:!wolfSSL error occurred, error = 162 line:40816 file:wolfssl-4.7.0-commercial/src

The right message was also logged:

RTI_Security_Authentication_getCertificate:{"DDS:Security:LogTopic":{"f":"10","s":"3","t":{"s":"1656525802","n":"388092999"},"h":"bld-ubuntu1804","i":"0.0.0.0","a":"RTI Secure DDS Application","p":"12300","k":"security","x":[{"DDS":[{"domain_id":"12"},{"guid":"9d69955f.b83e6145.974e667f.1c1"},{"plugin_class":"Authentication"},{"plugin_method":"RTI_Security_Authentication_getCertificate"}]}],"m":"Identity verification failed. Make sure it was signed by the right authority."}}

The wolfSSL error message made the error from the Security Plugins less noticeable. This issue, which only affected the debug libraries, has been fixed.

[RTI Issue ID SEC-1710]

6.4.6. Fixes Related to the Security Plugins SDK

6.4.6.1. Certificate Revocation Lists expired after 30 days

In previous releases of the Security Plugins SDK, a subset of the tests started failing after 30 days because Certificates Revocation Lists expired. The 30 days started counting from the moment RTI generated the CRLs. Therefore, users may have found that some SDK tests never passed. This issue has been fixed. The CRLs now have the same expiration time as the certificates: 5 years.

[RTI Issue ID SEC-1677]

6.4.7. Fixes Related to Shipped Examples

6.4.7.1. Secure Hello World example always linked OpenSSL dynamically

The C and traditional C++ hello_security examples always linked OpenSSL dynamically, even if the user wanted to use static linking. This issue has been fixed. Now, when linking on a Windows system with Visual Studio, the OpenSSL and crypt32 libraries are linked statically, unless you choose Debug DLL or Release DLL from the configuration pull-down menu of the provided projects. Or, when using a makefile, OpenSSL is now linked statically, unless you use pass the SHAREDLIB=1 argument to the make command.

[RTI Issue ID SEC-880]

6.4. What’s Fixed in 7.0.0