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:

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.

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.

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 having a proper MitM protection by setting the parameters

ccl/ssl/client/require_extended_master_secret = 1
ccl/ssl/client/allow_session_resumption_without_extended_master_secret = 0

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 our 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

The first advise was to use extension=extended_master_secret but this was corrected to use the one shown above.

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.