3

Quoting RFC 5246:

"Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error."

and

The Security Parameters

These security parameters are determined by the TLS Handshake
Protocol and provided as parameters to the TLS record layer in order
to initialize a connection state. SecurityParameters includes:

enum { null(0), (255) } CompressionMethod;

enum { server, client } ConnectionEnd;

enum { tls_prf_sha256 } PRFAlgorithm;

enum { null, rc4, 3des, aes } BulkCipherAlgorithm;

enum { stream, block, aead } CipherType;

enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, hmac_sha512} MACAlgorithm;

Does that mean that security parameters = cipher suite?

What would cause this kind of handshake failure? For example cipher suite mismatch?

I know it might be a basic question but I was struggling to find a clear explanation.

2

Does that mean that security parameters = cipher suite ?

The security parameters describe a state and include master secret, various random data used in the handshake etc. The cipher suite instead describes only a set of algorithm but not the actual state when using these algorithms. Apart from that only part of the security parameters depend on the cipher suite. Notably compression and the connection end are independent from the chosen cipher.

What would cause this kind of handshake failure ? For example cipher suite mismatch ?

The most common problem for this alert is probably that there is no overlap in the ciphers between client and server. But note that you often don't get a handshake_failure alert but just some generic handshake error because the server simply closed the connection on error.

  • Thank you @SteffenUllrich. How would you troubleshoot this type of failure ? We have an application that is connecting to the application server via a proxy. We don't get the error when we don't go over the proxy. We have a trace file from the proxy but I was considering to capture at the proxy and the app server simultaneously. Thank you! – adam86 Jul 3 '16 at 19:39
  • 1
    @adam86: troubleshooting TLS connectivity problems is complex. See noxxi.de/research/ssl-debugging.html for a deeper coverage of the issues and ways to debug. But in the simplest case: check if it works with specific clients and not with others and then find the difference, usually in protocol version and/or ciphers. – Steffen Ullrich Jul 3 '16 at 19:41
  • I was reviewing some Wireshark capture files from their wiki and I've found traces in which the server was advertising 95 ciphers Suites. If I capture without the proxy I can see that the client and the app server are advertising just a single one. Isn't this somehow strange ? Or is it possible that if the app server advertises only one Cipher Suite that it won't find a match from the proxy ? – adam86 Jul 3 '16 at 19:50
  • 1
    @adam86: A TLS server does not advertise any ciphers at all. I recommend you read How does SSL/TLS work to understand the TLS handshake. This is also important when you try to debug your problem. – Steffen Ullrich Jul 3 '16 at 20:33
  • Thank you @Steffen Ulrich. Is the cipher suite controlled by the OS itself ? I mean is it possible in case we have 2 NIC that each will advertise different ones ? Let's say one will have DHE ciphers deactivated? – adam86 Jul 4 '16 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.