Pitfall with the TLS Extended Master Secret Extension in PI/Java and ABAP systems

[JoeGoerlich]

Inspired by the blogpost Chronicles of a PI TLS 1.2 upgrade by engswee.yeoh I like to share some other pitfall you may want to avoid with the IAIK Library of your PI and other AS Java systems as well as the CCL.

Updates:
2023-03-09: Added informations about adjustments in CCL 8.5.48 which may have an impact on the EMS handling.
2023-02-19: Added section for 3rd party applications. Added hint that 3SAHKE relays on the key exchange algorithm.
2022-12-01: Added further information regarding the parameters ccl/ssl/*/allow_session_resumption_without_extended_master_secret.
2022-11-21: Added another pitfall when it comes to connect to SAP Support Backbone via https.

---

 

Extended Master Secret Extension

The Extended Master Secret extension provides a technique to prevent from man-in-the-middle attacks.

The Extended Master Secret extension along with the TLS Session Hash is described in RFC 7627 and you can find all the details in the link or read this writeup from Craig Young, Nov. 2015.

 

Update: As researchers pointed out, the 3SHAKE is only possible when RSA or DHE are used for the key exchange. A remediation could be to restrict the supported cipher suites to the ones using ECDHE for key exchange. With this you may decide to not require/enforce EMS.

How to enable this feature

The CommonCryptoLib (CCL) allows to enable the enforcement of the TLS Extended Master Secret. This could be leveraged, for example, to make the ICM strictly require each client to send the corresponding extension during the handshake and in each subsequent request when it acts as a server.

To enable the feature on server side the parameters

ccl/ssl/server/send_extended_master_secret = 1

ccl/ssl/server/require_extended_master_secret = 1

ccl/ssl/server/allow_session_resumption_without_extended_master_secret = 0

has to be set for the CCL.

Please note: The parameter ccl/ssl/server/allow_session_resumption_without_extended_master_secret allows to control the handling of situations described in RFC 7627, 5.4.

After that, all clients have to send the extension!

What happens when a client does not send the extension

If a client does not send the extension in its requests, connections can no longer be established and you may find the following error during the handshake:

[Thr 139702314211072] [ssl_parse_clienthello_tlsext]

[Thr 139702314211072] CCL[SSL]: Srv-000103D1: ########## TLSERROR: The peer did not send the extended master secret extension. [0xA060022A: Failed to perform new handshake during read

[Thr 139702314211072]

[Thr 139702314211072] CCL[SSL]: Srv-000103D1: Sending alert of level FATAL: handshake failure [ssl3_send_alert]

[Thr 139702314211072] CCL[SSL]: Srv-000103D1: ########## TLSERROR: SSL3 server handshake failed [0xA060022A: Failed to perform new handshake during read or write.]

[Thr 139702314211072]

If you wan't the ICM to send the Extended Master Secret extension when acting as a client, you have to set the parameter

ccl/ssl/client/send_extended_master_secret = 1

You also can enforce from client side to only communicate when this MitM protection is enabled by setting the parameters

ccl/ssl/client/require_extended_master_secret = 1

ccl/ssl/client/allow_session_resumption_without_extended_master_secret = 0

Please note: The parameter ccl/ssl/client/allow_session_resumption_without_extended_master_secret allows to control the handling of situations described in RFC 7627, 5.4.

Pitfall with SAP NW AS Java clients

As you know, the SAP NetWeaver AS Java does not rely on the CCL for outgoing connections, but uses the IAIK Library. As SAP PI runs on AS Java and serves many interfaces we for sure run into issues on such an important and meshed system.

After enforcing the Extended Master Secret extension in some of our ABAP systems, we got reports that connections from PI stopped working.

We started troubleshooting and analyzed the log files and traces. We identified that the IAIK library does not send the corresponding extension in its requests by default.

As it is not documented how to enable this, we opened a prio high case at SAP and provided the trace files showing the handshake errors along with a detailed description which circumstances lead to the issue and asked for advice how to configure the IAIK accordingly.

After more than 15 turnarounds of the case, we finally got the necessary information:

Adding the following line to the custom SSLContext.properties configuration file will enable the sending to the extension and connections can be established again.

extension=extended_master_secret.noncritical

Hint:
The first advise was to use extension=extended_master_secret but this was corrected to the one shown above. This is because it would allow only connections to servers which send the Extended Master Secret extension, similar to ccl/ssl/client/require_extended_master_secret = 1 and will not resume sessions which do not send the extension, similar to ccl/ssl/client/allow_session_resumption_without_extended_master_secret = 0.
In a PI dealing with interfaces to systems out of our control this would lead to interoperability.

Pitfall with SAP NW ABAP / ABAP Platform

As mentioned in the beginning, there are these parameters:

ccl/ssl/client/allow_session_resumption_without_extended_master_secret

ccl/ssl/server/allow_session_resumption_without_extended_master_secret

During our analysis of the connection issues from the PI systems to ABAP systems, we found some strange behaviour and it took us some time to realise why this happened.

Let's make a little excursus to establish a full understanding.

We use the method described in SAP Note 2338952 to store the CCL parameters in the DEFAULT.PFL of the SAP system and to link the CCL to look for its parameters in this file by setting an environment variable through the SAP Instance Agent. This is achieved by an entry in the DEFAULT.PFL:

SETENV_<xx> = CCL_PROFILE=$(DIR_PROFILE)/DEFAULT.PFL

With this method, an SAP basis admin can change CCL parameters using RZ10 and the changes will be active directly after saving the profile. They no longer have a need to access the OS to make changes for the CCL.

During the troubleshooting in our test system, the parameters for the CCL have been changed in the DEFAULT.PFL on the OS level using a text editor.

After the changes have been saved to the file, the CCL immediately used the parameters but suddenly stopped to use them after the profiles have been uploaded to RZ10.

To understand this, one must know that RZ10 has a length limitation for parameter names of 60 characters. These both parameters have a length of 70 characters. By uploading the profiles the parameter names have been cut after 60 characters and the CCL could no longer interpret them and just ignored them.

We informed SAP about this issue and a fix is promised for CCL >= 8.5.45.

 

Pitfall with SAP Support Backbone

In July/November 2020 SAP disabled the possibility to connect to their support backbone via RFC (SAP Note 2740667. Since then, one has to use the HTTP destinations to connect to apps.support.sap.com, notesdownloads.sap.com and alike (full list is provided in SAP note 3193172).

At time of writing those servers do not send the Extended Master Secret extension.

From the CCL traces:

[Thr 139779747575552] CCL[SSL]: Cli-000000AE: ########## TLSERROR: The peer did not send the extended master secret extension. [0xA060022A: Failed to perform new handshake during read or write.]

[…]

[Thr 139779747575552] The peer did not send the extended master secret extension.

 

And a test with openssl:

79> openssl s_client -connect notesdownloads.sap.com:443 | grep secret





depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA

verify return:1

depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1

verify return:1

depth=0 C = DE, ST = Baden-W\C3\BCrttemberg, L = Walldorf, O = SAP SE, CN = origin.softwaredownloads.sap.com

verify return:1



Extended master secret: no

 

80> openssl s_client -connect origin.notesdownloads.sap.com:443 | grep secret



depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA

verify return:1

depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1

verify return:1

depth=0 C = DE, ST = Baden-W\C3\BCrttemberg, L = Walldorf, O = SAP SE, CN = origin.softwaredownloads.sap.com

verify return:1



Extended master secret: no

 

Update (2023-03-09): SAP made some adjustments with CCL 8.5.48 which affects the handling if the Extended Master Secret is not present. This was announced with SAP note 3282670.

 

Pitfall with 3rd Party Applications

As 3rd party application may come with their own crypto library or relay on the crypto lib bundled with the OS, EMS may not be supported.

Manny Linux distributions still come with the OpenSSL 1.0.2 LTS which does not support EMS. Since EMS is considered as a new feature and not a security fix, it is most likely not backported by the vendors.

Update (2023-03-09): The adjustments of CCL 8.5.48 mentioned before may also have an effect on interfaces to 3rd party applications.