Skip to Content
Author's profile photo Eng Swee Yeoh

Supported TLS versions for outbound connections on Java stack

Update 15 June 2017: If you have arrived here in search for a solution for TLS 1.2 on PI, I suggest that you also check out my latest blog on the issue – Chronicles of a PI TLS 1.2 upgrade

Update 16 May 2016: Hot off the press! The solution is finally out in SAP Note 2284059 – Update of SSL library within NW Java server. Refer further comment by Markus Schalk in the comments section.

Introduction

One of the most interesting discussion threads in this space over the past few months has been iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake by Wilbert Karremans.

So why do I find it interesting, you might ask? Is it because it has garnered 50+ replies in a space of three months and continues to be an active thread? Is it because many other similar threads have come up as well? Yes, and yes, but more importantly, it is about a functionality which IMHO is increasingly becoming an important one, and yet there is no publicly available support from SAP (at the time of writing) for that functionality.

The functionality in question is the support for TLS versions above 1.0 when the AS Java is behaving as a client component. Another way to rephrase this with respect to PI is that there is no support on Java-based adapters for outbound connections to a web server on versions of HTTP TLS above 1.0.

The reason why this is important is apparent from the various threads on the same topic. Providers are dropping support for older versions of TLS which is likely due to the serious SSL/TLS security flaws that were discovered in recent years like POODLE and Heartbleed.

It is important to note that this applies only for the case when AS Java acts as a client component. As shown in the following diagram (courtesy of SAP Help), in such scenario the SAP Java Cryptographic Toolkit (a.k.a. IAIK) is used, and as mentioned by Peter Tari in the thread, it currently only supports TLS 1.0.

/wp-content/uploads/2016/04/lib_931772.png

In light of this, the reason for this blog post is to raise awareness to the wider community (because not everyone reads every thread) as this can be a potential issue during integration projects. Additionally, following are a couple of key learnings from the above mentioned thread that can prove useful to anyone who might potentially face this issue.

How to check SSL/TLS versions supported by web servers

In order to confirm if this is a potential integration issue, it is crucial to confirm the versions of SSL/TLS that are supported by a web server. This is not something that is readily available unless the web server owner provides it or explicitly mentions it. Fortunately, hidden in the following SAP note (mentioned in the above thread) is a handy Perl script that can do just this.

2110020 – Enabling TLS or disabling SSLv3 protocol versions on SAP WebDispatcher, or SAP WebAS (AS ABAP 6xx, 7xx or AS Java >= 710)

Do take note though that although the SAP Note contains this utility, the note is actually relevant for AS ABAP/Java as a server component.

In order to use this utility, download the attachment from the SAP Note and copy it to a system capable of running Perl scripts. This can be performed on your PI system if it is a Unix-based system. Otherwise, I personally have a copy of Cygwin handy for whenever I need to run some Unix related commands.

Once the script is in place, execute the script providing the server hostname and port, i.e. example using SCN’s site below:-

perl ssl-hellotest.pl scn.sap.com 443

Below is the output from the above execution, confirming that SSL 3.0 is not supported whilst TLS 1.0, 1.1 and 1.2 are supported.

/wp-content/uploads/2016/04/ssltest1_931778.png

For an example case that shows only TLS 1.2 is supported, check the output here.

OK, I know I need TLS > 1.0, now what?

As of time of writing, AFAIK there is no publicly available release of the SAP Java Cryptographic Toolkit that supports TLS > 1.0. According to Peter Tari’s responses, development is in progress to support TLS 1.2. However, a hunt down the forum threads reveals that this has been in the pipeline since late last year, so it is anyone’s guess when this would finally be publicly released.

So the best bet is to open a call/incident with SAP. This will both help raise the importance of this functionality, as well as provide access to a preliminary patch as an interim measure.

Assigned Tags

      10 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Raghuraman S
      Raghuraman S

      Very useful one Engg. Thanks for the share. 🙂

      Author's profile photo Markus Schalk
      Markus Schalk

      We are in touch with SAP for  approx. 1 year about this topic. Now we received the information, that public release of the SAP Java Cryptographic Toolkit (also known as IAIK) is coming close. We successfully tested the beta shipment already...

      I'll let you all know, when the official release is there.

      Author's profile photo Eng Swee Yeoh
      Eng Swee Yeoh
      Blog Post Author

      Great. I think there are a lot interested in the public availability of the release. Thanks for this update and waiting eagerly for your next update 😉

      Author's profile photo Markus Schalk
      Markus Schalk

      Here it comes, Note 2284059 provides the new IAIK release. Further codelines will be added soon.

      Watch out, we tested all SSL/TLS connections, and found multiple incompatible server which had to be updated before productive usage.

      You can use XPI Inspector with the authentication template (11) for testing.

      Author's profile photo Bhavesh Kantilal
      Bhavesh Kantilal

      Hello Markus,

      Good news indeed.

      Could you elaborate more on incompatible servers that needed updates? Was it on the IAIK release from SAP or was it on the Server you are connecting to? I assume it was on the IAIK shipped from SAP, but would be great to know!

      Also, can you let us know what kind of errors one can expect when we use the XPI Inspector for monitoring? Maybe a comparison between a successful and a failed logs?

      This might help future updates around. Thanks for your support 🙂

      Regards,

      Bhavesh

      Author's profile photo Markus Schalk
      Markus Schalk

      Hello Bhavesh,

      i tried to summary the stuff in a separate blog post. Hope it helps the community.

      Outbound support for TLS 1.1/1.2

      Regards,

      Markus

      Author's profile photo Jens Schwendemann
      Jens Schwendemann

      Hi all,

      very interesting read, indeed.

      Am I right in the assumption than PI (Dual Stack) 7.0 is not supported for client side TLS 1.2 (but only TLS 1.1)?

      I came to this assumption in combining note 2284059 which DOES NOT contain support package patches for 7.0 and note 2094598 which DOES mention the use of TLS 1.0 or TLS 1.1 as an alternative of (broken) SSLv3 but DOESN'T mention TLS 1.2

      Many thanks and kind regards

      Jens

      Author's profile photo Jens Schwendemann
      Jens Schwendemann

      ok, after reading this again I figured, that 2094598 is about AS Java as a SERVER not a CLIENT.

      So there probably ought to be NO support for Client side TLS 1.1 or 1.2 in PI 7.0

      Author's profile photo Markus Schalk
      Markus Schalk

      Dear Jens,

      I recommend you to read my blog Outbound support for TLS 1.1/1.2

      Mentioned note is just for client connections (going out from PI/PO) and there is no support for PI 7.0! Maximum support for PI 7.0 is TLS 1.0...

      Acting as a server, CommonCryptoLib is used and not IAIK. (See note 2004653 for further details)

      Regards

      Markus

      Author's profile photo Oscar Alejandro Aranquiz Cortes
      Oscar Alejandro Aranquiz Cortes

      Hi, everybody. I developed some interfaces SAP/ Salesforce and as you know, the latter will disable TLS1.0. This article has helped understand some points. Salesforce says Client and Server will need TLS>=1.1 but we’re sending a message from SF to PI(tls1.0) and it works. When PI sends it to SF it fails. After reading the page, I see that pi as client and as server use different protocols. Is that right? If so, how does that work? Can someone help me understand that? Thank you.