Inspired by the blogpost Chronicles of a PI TLS 1.2 upgrade by Eng Swee 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:
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.
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 useextension=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 toccl/ssl/client/require_extended_master_secret = 1
and will not resume sessions which do not send the extension, similar toccl/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-WC3BCrttemberg, 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-WC3BCrttemberg, L = Walldorf, O = SAP SE, CN = origin.softwaredownloads.sap.com
verify return:1
Extended master secret: no