CL_HTTP_CLIENT trying to use SSLv3, even though it's turned off?

[jonbbrooks]

I'm trying to eliminate the use of SSL 3.0 following the POODLE vulnerability disclosure. However, something is broken and I'm not sure how to un-break it. It might be a fundamental flaw.

I'm trying to request something from an HTTPS server. On this server, SSLv3 has been disabled. TLS 1.0, 1.1 and 1.2 are enabled. Weaker cipher suites are also disabled. CommonCryptoLib version 8.4.30 pl40 is installed on top of kernel 7.41 pl26. The configuration is quite well exposed here.

The problem is that when CL_HTTP_CLIENT makes the request - and the same happens testing an RFC connection created via SM59 - the following is dumped out into the ICM trace:

*** ERROR during SecuSSL_SessionStart() from SSL_connnect()==SSL_ERROR_SSL   session uses PSE file "E:\usr\sap\PDE\DVEBMGS00\sec\SAPSSLA.pse" SecuSSL_SessionStart: SSL_connnect() failed  (536875072/0x20001040)   => "SSL API error" >>            Begin of Secu-SSL Errorstack            >> 0x20001040  SAPCRYPTOLIB  SSL_connect SSL API error received a fatal SSLv3 handshake failure alert message from the peer 0xa0600266  SSL  ssl3_read_bytes received a fatal SSLv3 handshake failure alert message from the peer <<            End of Secu-SSL Errorstack   SSL_get_state()==0x2120 "SSLv3 read server hello A"   No certificate request received from Server   SSL NI-hdl 331: local=10.10.20.9:50551  peer=37.128.189.157:443 <<- ERROR: SapSSLSessionStart(sssl_hdl=00000000311F8560)==SSSLERR_SSL_CONNECT *** ERROR => SSL handshake with www.yesbadezimmer.de:443 failed: SSSLERR_SSL_CONNECT (-57) SAPCRYPTO:SSL_connect() failed [Thr 4832] SapSSLSessionStart()==SSSLERR_SSL_CONNECT   SSL:SSL_connnect() failed  (536875072/0x20001040)   => "SSL API error" >>      SecuSSL ErrStack: 0x20001040  SAPCRYPTOLIB  SSL_connect SSL API error received a fatal SSLv3 handshake failure alert message from the peer 0xa0600266  SSL  ssl3_read_bytes received a fatal SSLv3 handshake failure alert message from the peer <<   SSL:SSL_get_state()==0x2120 "SSLv3 read server hello A"   SSL NI-hdl 331: local=10.10.20.9:50551  peer=37.128.189.157:443   cli SSL session PSE "E:\usr\sap\PDE\DVEBMGS00\sec\SAPSSLA.pse"   Target Hostname="www.yesbadezimmer.de" [Thr 4832] {00080020} [icxxconn.c 2010]

Profile parameter ssl/ciphersuites is set to 129:HIGH and profile parameter ssl/client_ciphersuites is set to 128:HIGH. According to SAP Note 510007, this should mean that an SSL 2.0 CLIENT-HELLO is allowable for backwards compatibility reasons for inbound HTTPS connections, SSLv3 is disabled, TLS 1.0 is enabled, and only the cipher suites TLS_RSA_WITH_AES128_CBC_SHA and TLS_RSA_WITH_AES256_CBC_SHA are enabled for both inbound and outbound communication over HTTPS. SSL_RSA_WITH_3DES_EDE_CBC_SHA should be disabled because it requires SSLv3. Performing a scan against this server of the available cipher suites reveals a typographical error in the SAP Note, as actually SSL_RSA_WITH_3DES_EDE_CBC_SHA should read TLS_RSA_WITH_3DES_EDE_CBC_SHA.

The upshot of this is that, assuming the profile parameters are being correctly respected, no communication with HTTPS services should ever be attempted via SSL 3.0, but it clearly is trying it. Can anyone else replicate what I'm seeing here and/or does anyone have a workaround or fix for this issue? It's the line in the ICM trace stating that it "received a fatal SSLv3 handshake failure alert message from the peer" which is making me think that there's something fundamentally wrong here.

[jonbbrooks]

Update: I found the problem. The error message is completely unhelpful, but if one of the cipher suites supported by SAP isn't available on the server with which you're trying to communicate, then even if you disable SSLv3, it will still fall back to it (for some unknown reason). I managed to get communication working again by enabling TLS_RSA_WITH_AES256_CBC_SHA on the target server. It's a shame, as there's now the possibility that someone could communicate with that server and not be protected by Forward Secrecy, but unfortunately I don't have any choice until SAP get their act together and start supporting things like TLS 1.1 and 1.2.

[martin_voros]

Hi,

regarding wrong prefix. There seems to be a legacy reason mentioned here. This means that there does not seem to be a way to disable SSLv3 in ABAP AS. What happens if you allow SSL_RSA_WITH_3DES_EDE_CBC_SHA. It's a valid option for TLS v1.0 but does it enable SSLv3 as well?

Also that behavior seems to be wrong. Why should all combinations be enabled on server? A client and server need to agree on one particular suite. The behavior seems to be wrong and should be addressed by SAP.

I believe both issues should be addressed as security notes.

Cheers

[jonbbrooks]

Hi Martin,

The thread you reference is specific to Java. SSL_RSA_WITH_3DES_EDE_CBC_SHA is already enabled, but like I say, it's a typo in the SAP Note. It's cipher suite 0x00,0x0A, which is variously known as TLS_RSA_WITH_3DES_EDE_CBC_SHA, DES-CBC3-SHA and TLS_RSA_3DES_EDE_CBC_SHA1. The typo has been made by the developers of the Zeus Load Balancer as well in the past, and possibly others. It certainly doesn't allow communication over SSL 3.0 with that cipher suite. However, when it can't find a TLS 1.0 cipher suite it can use, it does appear to be attempting an SSL 3.0 handshake, which is just wrong, unless the ICM trace is displaying incorrect information.

The lack of support for TLS 1.1, TLS 1.2, Diffie-Hellman key exchange, the TLS_FALLBACK_SCSV flag, the Heartbeat extension, ticket-based session resumption, OCSP stapling, Strict Transport Security, elliptic curve cryptography, GCM, SHA384, SHA256 and probably a few other things is a bit disappointing to say the least. From reading the SAP Note, it also doesn't appear to be possible to disable the weaker 3DES cipher suite when enabling the HIGH strength cipher suites - only the 3DES ones - and if you can disable it, it's not documented.

I'll open a ticket.

[martin_voros]

Hi,

at least that it's a good news that it does not enable SSLv3. It  sounds like a bug that it falls back to SSLv3 when it can't agree on TLS cipher suite.

Regarding lack of support for new stuff. I agree that it should be better. I think it would be really nice if we could have at least a ciphersuite with perfect forward secrecy. The possible workaround is to use some other reverse proxy with more modern TLS implementation. Regarding 3DES you can disable it. Here is a quote from 510007.

You can use the category to define which ciphersuites are relevant and you can use the category sequence to define which are the preferred ciphersuites; you can specify

   "!mMD5", "!mSHA1", or "!eNULL", "!eRC4", "!eDES", "!eRC2"

to remove specific ciphersuites from the selected categories in the list of selectable ciphersuites.

So adding !e3DES should turn it off.

Cheers

[martin_voros]

I just noticed that you have ssl/client_ciphersuites set to 128:HIGH. Isn't this reason why it falls back to SSLv3?

Also I know that the thread I mentioned is specific for Java but I think it explains why this cipher suite has prefix SSL_ even it now belongs to TLS. It seems that it was introduced before TLS was finalized.

Cheers

[jonbbrooks]

Unfortunately, !e3DES isn't an option and it doesn't do anything - just !eDES. 128:HIGH means TLS 1.0 enabled, SSL 3.0 disabled, SSL 2.0-style CLIENT-HELLO disabled, only cipher suites described as "high" (not that they are) strength enabled.

Whilst the reverse proxy is a reasonable-ish workaround, it introduces unnecessary complexity, and doesn't work quite so well for outbound stuff, and really we should be able to use the Web Dispatcher as the reverse proxy which has exactly the same problems.