1

I'm currently trying to get a bidirectional TLS 1.2 connection working between 2 local Karaf-based XMLRPC servers that by design only accept POST requests. The environment is Windows 10 and both XMLRPC servers are running in the same JDK: 1.8.172. I'm currently at the point that the client can send a ClientHello to the server, but the answer from the server is a Handshake-failure, with an examination by Wireshark of the response stating it's a Handshake-Failure(40). I understand this means that the server and client do not have any ciphersuites in common. I find this hard to believe considering they both run in the exact same JVM with the same java -Dhttps.protocols property (TLSv1,TLSv1.1,TLSv1.2 on both ends).

The client sends the following TLS ciphersuites in the ClientHello:

[TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

I'm now trying to figure out the TLS suites supported by the server. the problem is that I've tried using Nmap for this, but Nmap uses GET requests, which are rejected immediately by XMLRPC (this is hardcoded: it has a hardcoded check that the Method is POST, and immediately throws a custom BadRequestException if this isn't the case).

How can I check the supported TLS suites of a local server that only accepts POST requests?

Improve this question

1 Answer 1

Reset to default
5

It is totally irrelevant if GET or POST is used. The TLS handshake is done before any HTTP request is even send. So if the handshake fails it means that neither GET nor POST is possible. If the server will only accept POST and a GET was send the server will reply with an HTTP level error. It cannot cause a TLS handshake error since the TLS handshake was already finished and cannot fail anymore.

... with an examination by Wireshark of the response stating it's a Handshake-Failure(40). I understand this means that the server and client do not have any ciphersuites in common.

Actually, no shared ciphers is only one of several possible reasons of a handshake error. Depending on which state this happens it might for example also a lack of a requested client certificate or the wrong client certificate. And no shared ciphers might for example be caused by a failure to load the certificates in the server which means that it cannot use any ciphers which require certificate based authentication.

Improve this answer
4
  • according to multiple sources I consulted, a 40 handshake-failure is an indication of a Ciphersuite failure: docs.apigee.com/api-platform/troubleshoot/runtime/… is one of them. I'm also fairly sure that it's not a certificate error, because I turned on Javax.net logging and both client and server explicitly say the server I self-signed for this machine are in the server_keystore file that they both load during the setup.
    – Nzall
    Commented Feb 7, 2020 at 16:53
  • 1
    @Nzall: Exactly this link says that a cipher suite mismatch is one of several possible causes of an handshake error and not that a handshake error can only happen when no ciphers are shared. Believe me, I've seen enough handshake errors not caused by a cipher mismatch. If you would provide the full debug logging you have (but better in a new question) one might find out what the real problem is.
    – Steffen Ullrich
    Commented Feb 7, 2020 at 16:56
  • So you're saying that if I provide a full log of the request as debug logged by Java in a new question, it's on-topic as a support question? Also, that article implies that the error code behind the Handshake-Failure indicates what kind of Handshake error it is. If this isn't the case, then what does it imply?
    – Nzall
    Commented Feb 7, 2020 at 17:07
  • 1
    @Nzall: There are many such questions at least at stackoverflow.com so it might be better on-topic there. Handshake error says just this: "something" went wrong. TLS does not offer very helpful error messages. There would actually be a "no shared cipher" alert in case of cipher mismatch but not every TLS stack is using it.
    – Steffen Ullrich
    Commented Feb 7, 2020 at 17:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .