2

I have Java TLS server and have switched from the original SunJSSE provider to BCJSSE (BouncyCastle JSSE FIPS, v1.0.10). Now if someone tries to query my server with nmap -sT -Pn --script ssl-cert,ssl-enum-ciphers -p , ciphers having enabled DHE key exchange algorithm were shown and the handshake was successful:

ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A

Having the BCJSSE provider, which claims to support the above DHE ciphers, nmap returns:

 ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A

When running:

openssl s_client -tls1_2 -cipher DHE-RSA-AES128-CCM -connect <host> <port>

actually the handshake is successful with the DHE ciphers. However, running curl, compiled with the very same version of openssl:

curl -vvv -k https://<host>:<port>--tlsv1.2 --ciphers DHE-RSA-AES128-CCM -u <user>:<pass> -c /tmp/cookie

the result is:

* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

The old crypto provider used to handshake successfully for each of the supported ciphers (not the last one which is available only in BC).

The BCJSSE documentation says: Cipher suite name: TLS_DHE_RSA_WITH_AES_128_CCM FIPS mode: N which I interpret as supported.

So, does anyone knows why there is a difference between the nmap outputs and how it is possible to have a successful handshake with s_client but curl refuses to establish such a secure connection. And is there something particular to be fixed here and how, or this might be considered as expected behavior?

Tsvetan Benchev
  • 21
  • 2
  • Actually, they are enabled by default and as I mentioned above, using openssl the handshake is successful. If it is not enabled at all, this handshake would never happen. – Tsvetan Benchev Jul 13 '20 at 13:15
  • From the error message it seems like curl still uses an SSLv3 client hello message. As SSLv3 is usually disabled and unsupported by modern servers the curl request fails. Is it possible that you are using an old version of curl? – Robert Jul 13 '20 at 13:21
  • Nope, actually I am using the most recent version: curl 7.71.1 (x86_64-pc-linux-gnu) libcurl/7.71.1 OpenSSL/1.1.1g zlib/1.2.7 Release-Date: 2020-07-01 – Tsvetan Benchev Jul 13 '20 at 13:23
  • Use Wireshark, capture the CLIENT_HELLO request from curl and look at the used TLS version – Robert Jul 13 '20 at 14:19
  • The TLS version appears to be the correct 0x0303/ v1.2 – Tsvetan Benchev Jul 13 '20 at 15:15

0 Answers0