2.2.2.2. RTI Security Plugins

The following issues affect backward compatibility in RTI Security Plugins when migrating from release 7.0.0 to release 7.1.0.

Attention

For important information on new and deprecated features in 7.1.0, see What’s New in 7.1.0 in the Security Plugins Release Notes.

2.2.2.2.1. Changes to building an application

2.2.2.2.2. OpenSSL upgrade

Release 7.1.0 of the Security Plugins uses OpenSSL® 1.1.1t and OpenSSL 3.0.8. (Release 7.0.0 used OpenSSL 1.1.1n.)

Security Plugins 7.1.0 includes two sets of target bundles: rti_security_plugins-7.1.0-target-openssl-1.1.1-<architecture>.rtipkg and rti_security_plugins-7.1.0-target-openssl-3.0-<architecture>.rtipkg. The openssl-1.1.1 version is API-compatible with OpenSSL versions 1.1.0 through 1.1.1t, not with versions earlier than OpenSSL 1.1.0. The openssl-3.0 version is API-compatible with OpenSSL versions 3.0.0 through 3.0.8, not with versions earlier than OpenSSL 3.0.0. Note that Security Plugins 7.1.0 has only been tested by RTI using OpenSSL 1.1.1t and OpenSSL 3.0.8. If you need Security Plugins 7.1.0 to run against older versions of OpenSSL, please contact support@rti.com.

OpenSSL 1.1.1 will only be supported until 2023-09-11 (https://www.openssl.org/policies/releasestrat.html), so it is recommended that you upgrade the version of OpenSSL that you are using to OpenSSL 3.0.8 for release 7.1.0.

For instructions on installing the latest version of OpenSSL, see the RTI Security Plugins Installation Guide 7.1.0.

2.2.2.2.2.1. Degradation of Security Plugins performance when switching from OpenSSL 1.1.1 to OpenSSL 3.0

The throughput of the Security Plugins for OpenSSL 3.0 is worse than that of the Security Plugins for OpenSSL 1.1.1. This degradation is not due to the Security Plugins; it is due to the OpenSSL cryptographic library. OpenSSL 3.0.8 is slower than OpenSSL 1.1.1t, at least for most algorithms that the Security Plugins support. The root cause is this OpenSSL issue: https://github.com/openssl/openssl/issues/20171. See Cryptographic Libraries, in the RTI Connext Performance Benchmarks, for more information.

2.2.2.2.3. wolfSSL upgrade

Starting in release 7.1.0, the Security Plugins for wolfSSL are now based on wolfSSL version 5.5.1. Starting with 7.1.0, the Security Plugins are API-compatible with wolfSSL version 5.5.1, not with versions earlier than wolfSSL 5.5.1. Note that the Security Plugins have only been tested by RTI using wolfSSL 5.5.1.

See the RTI Security Plugins Installation Guide.

2.2.2.2.4. Updated shipped examples to support different cryptographic libraries

Release 7.1.0 added supports for compiling the security shipped examples (the C, C++ and Java hello_security examples, and the hello_banish C example) using any of the available cryptographic libraries (OpenSSL 3.0, OpenSSL 1.1.1, or wolfSSL 5.5). Use the cryptographic library matching your installation of the Security Plugins. When linking statically, the default cryptographic library is now OpenSSL 3.0. (Release 7.0.0’s default was OpenSSL 1.1.1.)

The examples for Windows systems now include new build modes, so you can choose the cryptographic library. On Linux and macOS systems, you can indicate the cryptographic library as a parameter of the make command when compiling the example.

Please see the hello_security READ_ME.txt files for more details.

2.2.2.2.5. Wire Compatibility

2.2.2.2.5.1. Enabling key revisions is not backwards compatible for certain DataWriters

When enabling key revisions by setting the property dds.participant.trust_plugins.key_revision_max_history_depth to a value other than 0, a 7.1.0 DataWriter will not communicate with a 7.0.0 DataReader (or vice-versa) if the DataWriter’s DomainParticipant calls banish_ignored_participants and both of the following conditions are true:

  • In the Governance Document, the DataWriter’s topic_rule has metadata_protection_kind and data_protection_kind set to values other than NONE.

  • At least one of the following conditions is true:

    • In the DataWriter’s DomainParticipant’s QoS, the value of cryptography.share_key_for_metadata_and_data_protection is false or 0.

    • In the Governance Document, the DataWriter’s topic_rule has data_protection_kind set to a value other than the value of metadata_protection_kind.

Under both of those conditions, the DataReader will get this error upon trying to decode a submessage from the DataWriter:

EVP_DecryptFinal_ex failed with error

This compatibility issue is a result of fixing RTI Issue ID SEC-1825. For details, see What’s Fixed in 7.1.0 in the Security Plugins Release Notes.

2.2.2.2.6. (Experimental) Simple Participant Discovery 2.0 interaction with Security Plugins

In releases 7.0.0 and 7.1.0, there are known scalability challenges with large-scale systems using the Security Plugins in combination with Simple Participant Discovery 2.0, where “large” means multiple hundreds of participants discovering each other at once. These issues may manifest as excess bandwidth usage, lack of complete discovery, liveliness lost events, or incomplete authentication periods. These issues have been addressed in release 7.2.0. Simple Participant Discovery 2.0 is no longer experimental in 7.2.0.