Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How can i activate TLS 1.1+ on SAP AS JAVA 7.31 client-side?

matthias_isenburg
Participant
0 Kudos

I only know sap note"510007 - Setting up SSL on Application Server ABAP".

If i apply the informations of this note to AS JAVA,

"The built-in defaults for the client-side enables only SSLv3 + TLSv1.0 for SAPCRYPTO 5.5.5pl28+ and CommonCryptoLib 8, corresponding to client-side protocol version flags (128+64) = 192.  It is recommended to request TLS protocol version TLSv1.1 and TLSv1.2 with the flags "Best" and "NO_GAP", because only the latter is future-friendly and is fully compatible with older libraries."

i have to set the following sap profile parameters, like for example:

ssl/ciphersuites = 135:HIGH:MEDIUM:+e3DES

ssl/client_ciphersuites = 198:HIGH:MEDIUM:+e3DES

Unfortunately the AS Java already "requesting version 3.1..."

I suspect that these sap profile parameters don't work for AS JAVA?

Any experiences?

Any ideas?

Thanks in advance,

Matthias

- SAP NW PO 731 SPS12 (AS JAVA only)

- Currently we use CommonCryptoLib (SAPCRYPTOLIB) Version 8.4.37 pl40 (May 12 2015) MT-safe.

- Kernel = 721_EXT 64Bit Patch 300

1 ACCEPTED SOLUTION

LutzR
Active Contributor
0 Kudos

Hi Matthias,

I don't know if my answer ist still of some value but I think I should add what I found out.

What I am writing here was clarified in an incident with SAP development (BC-JAS-SEC-CPG) which is still not closed.

Configuring ssl/client_ciphersuites on an AS JAVA does not influence it's behaviour as an HTTP client in any kind of way. Documentation is ambiguous.

TLS client behaviour is provided by iaik JAVA libraries. These libraries currently do not support TLS 1.2 in any NetWeaver release.

Our problem is that we have an SaaS partner who wants to deactivate everything older than TLS 1.2 on their servers for security considerations and german BSI compliance.

Today our PI does clearly not support TLS 1.2 when connecting to this service.

SAP promised to deliver new libraries with TLS 1.2 support. But they did not deliver for months now.

SAP also was not able or willing to explain how to disable insecure ciphersuites like RC4 on newer 7.X systems. (I know how to do it on 7.0X systems using good old Visual Administrator).

We would appreciate your support. Just file an incident to BC-JAS-SEC-CPG.

Regards, Lutz

23 REPLIES 23

martin_voros
Active Contributor
0 Kudos

Hi,

have you seen the following note?

2092630 - Turning off SSLv3 on SAP NETWEAVER AS ABAP and AS JAVA, and on SAP HANA XS


Cheers

0 Kudos

Thanks Martin. Near all is clear now.

Only one thing,

Our requirement:

- SAP NW PO 731 SPS12 (AS JAVA only)

- Currently we use CommonCryptoLib (SAPCRYPTOLIB) Version 8.4.37 pl40 (May 12 2015) MT-safe.

- Kernel = 721_EXT 64Bit Patch 300

My question:

Default / Built-in cipher suite configuration settings from sap note510007 - Setting up SSL on Application Server ABAB:

For NW Rel. 70x, 71x, 72x with Kernel patch 1433874,

ssl/ciphersuites = HIGH:MEDIUM:+e3DES:LOW:EXPORT:!aNULL:!eNULL

ssl/client_ciphersuites = <undefined>

That means, i can define and use the profile parameter ssl/client_ciphersuites?

Because like described in,

Managing the Credentials and Trusted Certificates to Use SSL

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/14/29236de1864c6e8d46e77192adaa95/frameset.htm

"The cipher suites for outbound SSL connections cannot be managed."

What is truth?

Thanks in advance,

Matthias

0 Kudos

I would say that the option works for Java AS as well but I can't confirm it. My guess is that the documentation has not been updated. For example check this discussion:

it confirms that you can control cipher suites used by outbound connection from Java AS. To be 100% sure, you can test it by yourself.

Cheers

LutzR
Active Contributor
0 Kudos

Hi Matthias,

I don't know if my answer ist still of some value but I think I should add what I found out.

What I am writing here was clarified in an incident with SAP development (BC-JAS-SEC-CPG) which is still not closed.

Configuring ssl/client_ciphersuites on an AS JAVA does not influence it's behaviour as an HTTP client in any kind of way. Documentation is ambiguous.

TLS client behaviour is provided by iaik JAVA libraries. These libraries currently do not support TLS 1.2 in any NetWeaver release.

Our problem is that we have an SaaS partner who wants to deactivate everything older than TLS 1.2 on their servers for security considerations and german BSI compliance.

Today our PI does clearly not support TLS 1.2 when connecting to this service.

SAP promised to deliver new libraries with TLS 1.2 support. But they did not deliver for months now.

SAP also was not able or willing to explain how to disable insecure ciphersuites like RC4 on newer 7.X systems. (I know how to do it on 7.0X systems using good old Visual Administrator).

We would appreciate your support. Just file an incident to BC-JAS-SEC-CPG.

Regards, Lutz

0 Kudos

Hi Lutz, All is right. We are in the same situation, still waiting for the new libraries by a open SAP Ticket (BC-JAS-SEC-CPG). Regards, Matthias

0 Kudos

Hi Matthias

are there any news (i. e. new libraries) or are you still waiting?
A partner will only accept TLS1.2 secured Connections - so we have to make our AS JAVA PI TLS 1.2 ready.

Regards
Edgar

LutzR
Active Contributor
0 Kudos

Hi Edgar, my incident concerning this @ BC-JAS-SEC-CPG is still open, untouched and unsolved for months. We are currently moving functionality away from the JAVA stack to ABAP to work around this. Quite ridiculous.

Regards,

Lutz

0 Kudos

Hi Lutz,
thank you for your answer even if it contains bad news.
You are absolutely right: Moving functionality to ABAP can only count as an work around.
In our case it's not an real option because we want to use soap Adapter - so we can't replace it on ABAP-Stack.
Let me know if you hear something  new. We will also open an incident - let's see what happens

Regards
Edgar

Former Member
0 Kudos

Hi Edger,

I am also facing the same problem.

Was this resolved? did you get any response from SAP.

Did you find any other solution to make a connection with TLS 1.1/1.2?

Regards,

Veerendra.

0 Kudos

Hi Veerendra,

unfortunately there are no news concerning this topic - there is still no solution.

Regards
Edgar

LutzR
Active Contributor
0 Kudos

Hi all,

SAP now proposes a solution by note 2284059 https://launchpad.support.sap.com/#/notes/2284059.

But it contains only half of the solution:

  • Yes, TLS 1.2 is supported now
  • But only RSA key exchchange and no ECDHE (aka Perfect Forward Secrecy). PFS has been state of the art for a few years now and is required by german BSI regulations.
  • It is still not told how to exclude deprecated ciphers like RC4 and 3DES from the cipher suite list

Regards,

Lutz

0 Kudos

Hi Lutz,

thank you for sharing this information.

We will have a try with the new libraries.

Regards Edgar

0 Kudos

Lutz Rottmann wrote:

Hi all,

SAP now proposes a solution by note 2284059 https://launchpad.support.sap.com/#/notes/2284059.

But it contains only half of the solution:

  • Yes, TLS 1.2 is supported now
  • But only RSA key exchchange and no ECDHE (aka Perfect Forward Secrecy). PFS has been state of the art for a few years now and is required by german BSI regulations.
  • It is still not told how to exclude deprecated ciphers like RC4 and 3DES from the cipher suite list

Regards,

Lutz

Correct, SAP Note 2284059 is what you need for outgoing/client TLSv1.2 in AS Java, e.g. for SOAP Adapter.

TLS cipher suites with ECDHE has been, and still is NON-Standard!  (rfc4492 is informational rather than standards track)

TLS cipher suites with DHE are severly flawed in large parts of the installed base, and hurried enabling of TLS DHE cipher suites resulted in widespread loss of security (see the LOGJAM paper).  The DHE problems have been well-known since 2008, see

    [TLS] Short Ephermal Diffie-Hellman keys

The BSI paperwork is a recommendation, rather than a hard requirement, and BSI obviously recommend(ed) something long-known seriously problematic (TLS DHE), so please take the entire BSI advice with a grain of salt.  It is primarily a fashion statement, rather than a form of appropriate risk management based on scientific facts and responsible research.   The 2014 guideline from NIST is much better in that respect (NIST didn't make a specific fashion statement without researching facts first, and they deferred risk management to the consumer, because there are usage scenarios where the original security gurarantees of the TLS protocol, described in rfc5246, Appendix F are sufficient, and where TLSv1.0 is therefore perfectly sufficient.  Not everything is as security-broken as web browsers.  POODLE is a browser-only problem).

The situation right now is that Netweaver AS ABAP components (using CommonCryptoLib) are not interoperable with AS Java SSL client (using IAIK) on PFS cipher suites, because CommonCryptoLib supports only ECDHE and SAP's OEM IAIK toolkit supports only DHE cipher suites.

Why does CCL not support DHE?  DHE with keys <=1024 is well-known insecure (and slow), and DHE with keys > 1024 is well-known interoperability-impaired (Oracle Java the most notorious problem and reeeealllly ssssllllooooowwwww).  It's fair to say that TLS DHE is broken beyond repair (because of the interop problems).

-Martin

martin_voros
Active Contributor
0 Kudos

Hi,

I agree with your comment regarding DHE but what are the options if customer wants to implement PFS? Everywhere you find that the suites with PFS should have preference. E.g.

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Server_Protocol_and_Cipher_Co...

https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29

Even NIST document mentioned by you flags ECDHE suites as SHOULD which can be translated as recommended.

If I understand it correctly ABAP AS is fine because it supports ECDHE but that's not the case for Java AS. Why Java SSL client can't be updated to support modern cipher suites?

Cheers

LutzR
Active Contributor
0 Kudos

Hi Martin Rex,

unfortunately in my example case I do only control the client side. The server side is controlled by an SAAS/Cloud provider. This cloud provider serves many customers. This is about HR data so the provider might tend to be overprotective.

So you can tell me BSI is a fashion statement. As long as our business partners take it for granted I have no choice but to adapt.

Once again: this is not my choice.

Since this BSI recommendation is three years old this development is no surprise to anybody. But that there is no full solution from SAP and that we had to wait for nearly one year to get half (TLS 1.2) takes us by surprise.

You should know that there was already functionality moved from JAVA to ABAP side. This is reality.

And you should know that people are starting to implement reverse proxies as protocol converters to keep business running. That is reality too.

Migration projects towards PI were stopped. This is reality.

Reality does not care about what you are telling us about BSI.

Regards,

Lutz

0 Kudos

The (OEM) Java SSL IAIK/iSaSiLk Toolkit, that SAP is shipping with/for SAP Netweaver AS Java(including the TLSv1.2-capable update in SAP Note 2284059), does not support TLS cipher suites with ECDHE key exchange.  DHE key exchange is supported (in old and new).  I guess that this may change in the future, given that there is a strong preference for ECDHE in addition to the performance, security and interop problems of DHE in the installed base.  I can only comment on what is there.

With regard to the issue of "modern" cipher suites -- I'm sorry, they're first of all fancy, and AES-GCM is well-known brittle/fragile.  The original TLS cipher suites are proven and reliable, their alleged weaknesses highly academic and completely negligible in practice.  The security problems and brittleness (of a few implementations) of the fancy new TLS cipher suites, on the other hand, are extremely serious and painfully real, and quite practical see e.g.

   “Forbidden attack” makes dozens of HTTPS Visa sites vulnerable to tampering | Ars Technica

   https://eprint.iacr.org/2016/475

Please keep in mind, the "cutting edge" is also the "bleeding edge", the early bird is the breakfast for the early cat.  Those who didn't see this coming, just didn't pay attention.

The other problem is with TLS protocol versions > TLSv1.0.  The security benefits of TLSv1.2 over TLSv1.0 are completely negligible for whole classes of usage scenarios.  And using TLSv1.0 with SSL client cert authentication beats TLSv1.2 with server-only authentication easily, hands down.

But the real problem is the non-marginal interoperability issues with TLSv1.2 (and with TLS extensions) in the installed base.  By far the highest interop is achieved with extension-less TLSv1.0.  Sending TLS protocol versions > TLSv1.0 or TLS extensions results in interop problems.  So far, the TLS IETF working group has been refusing to address and fix the issue, by specifying a fully backwards compatible negotiation scheme, that succeeds in direct successful & protected negotiation of the most desirable TLS protocol features.  Rather than working on a protocol-level fix for the problem, the web browser folks added dirty hacks into browsers, which completely subvert the TLS handshake protection, the "Downgrade Dance" vulnerability in web browsers, which is target of the POODLE attack.

What we are seeing is

  - production services that are TLSv1.0-only, TLS-version-tolerant, but will abort handshake on presence of TLS extensions

  - Microsoft Windows 2008R2 / 2012R2 servers, which will choke and abort the TLS handshake when receiving an

     extension-less TLS ClientHello that offers TLSv1.2 (the handshake succeeds if at most TLSv1.1 is offered).

The bugs are real, they're roadblocking adoption of TLSv1.2, they've been known for a while, they aren't fixed by the software vendors/suppliers.

Negotiating TLSv1.0 with both works just fine, but no choice of TLSv1.2 parameters will result in a successful TLS handshake with both.

As described, the security benefits of TLSv1.2 are marginal and negligible in practice.

Those who issue recommendations to disable TLSv1.0 (rather than prefer TLSv1.2) are either clueless or acting irresponsible at the current state of the technology and the factual situation of the installed base with respect to interoperability.

Another look at the TLS mess:

  https://www.imperialviolet.org/2016/05/16/agility.html

What Adam fails to mention, though is that there is a protocol extensibility in TLS that has always been working quite well: TLS cipher suites.  It would be quite easy and feasible to use a TLS cipher suite codepoint as a way forward to negotiate the most desirable TLS protocol version and features in a transparent and fully protected fashion (while it may not be the original pure purpose of TLS cipher suite code points to be used for this task, we know it works just fine--been there, done that: rfc5746), there has been fierce resistance in the TLS working group, because of the "lack of beauty" or lack of "academic purity" in such an approach.  So for roughly 10 years the world has been roadblocked with this mess and IETF TLS WG inactivity.

I would love to see technical leadership take precedence in the IETF over the TLS high priest cult situation, to define a means for a smooth migration for using TLSv1.2 instead of a breaking change that is currently necessary, at just a little extra effort.

-Martin

martin_voros
Active Contributor
0 Kudos

Hi,

thanks for your response. I understand why SAP wants to be conservative as anything that is introduced needs to be supported for long time. But PFS should not be categorized as bleeding edge in 2016 and there are basically two options how to do it now: DHE with >2048bit keys or ECDHE. Even part of SAP, that is responsible for ABAP AS, confirmed that ECDHE is worth supporting. Hence providing support for ECDHE in Java libs does not seem to me like a unreasonable request. And having PI that is built on top of Java AS as an integration system without supporting PFS sounds weird.

Cheers,

Martin

Former Member
0 Kudos

Hi Lutz,

Refer to this note : 2284059,   In order to enable SAP Java stack ( e.g. SAP PI) to talk with SaaS which only support TLS 1.1/1.2 above.

  We will need to update the SERVERCORE component to the corresponding patch level mentioned in the note ? ( e.g. 7.31 SP17 = have to update until patch level 20 ).

  Or we can enable it ( the support of TLS1.1 / 1.2 ) manually ?

Best Regards,

Ken

LutzR
Active Contributor
0 Kudos

Hi Ken,

there is no TLS 1.1/1.2 without software update. Some of us received new "IAIK libraries" for testing. So maybe exchanging just these libraries might be enough. But I would not dare because there was also some infrastructure built to configure ciphersuites (see chapter 5 of note 2284059).

So I personally strongly recommend to do a regular update.

Regards,

Lutz

Former Member
0 Kudos

Hi Lutz,

  Thanks for the info..

  I believed in general there should not be any customize configuration needed as after the patching, the TLS1.1 / 1.2 will be supported by SAP java stack ( e.g. PI ) right ?

Best Regards,

Ken

LutzR
Active Contributor
0 Kudos

Hi Ken, have a look at chapter 5 of the note and you will understand what can be customized.

Customization is for enhancing security (e.g. by deactivating deprecated RC4) and for tuning compatibility with some flags. It is not "needed" in this basic way.

Regards,

Lutz

0 Kudos

Hi Luitz,

If we implement note 2284059 will it have impact on the other system's connectivity who uses certificates for Authentication?


FYI Currently we are using SAP PO 7.4(Single Stack)

Regards,

Shaik

VijayKonam
Active Contributor
0 Kudos

Hello Lutz or Mathiaz,

Any update on this one? We are on 7.31 and would like to enable TLS on our Java engine. Would Implementing this note cause have any side effects on already running SSL 3.0 interfaces?

Regards,

VJ