Can an SSL client send CLIENT HELLO with version 3.2 and NOT negotiate 3.1. For sslv2 and 3, one could do that by sending ssl23 CLIENT HELLO or SSL3. Please provide input on how one can support 3.2 but NOT 3.1 or if it is even possible.


There is a theoretical way which is explained in appendix E of RFC 5246; but its implementation is not necessarily easy.

In the ClientHello message, the client sends a "protocol version" which is the highest that the client supports (and is willing to use). This includes the implicit message "but I may support some older versions as well". The server then chooses the version which will be used, and states it in its ServerHello message. For instance, the client may have sent "up to TLS 1.1" (encoded as 0x0302) and the server could respond "we'll do TLS 1.0" (encoded as 0x0301).

There is no way for the client to proactively announce exclusions (as in: "I support TLS 1.1 but I don't want to do TLS 1.0"). However, if the server tries to use a protocol version that the client does not want to support, then the client always has the possibility to close the connection. Appendix E says that:

If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection.

In all generality, if the client wishes to support only a non-contiguous set of protocol versions, then he can enforce that by dint of using several connection attempts. For instance, suppose that, for some reason, the client wants to do TLS 1.1 or SSL 3.0, but not TLS 1.0. In that case, the client may first send a ClientHello specifying TLS 1.1 as highest supported version, and, if the server tries to use TLS 1.0, the client may close the connection (preferably with the "protocol_version" alert message), and then connect again, this time sending a ClientHello specifying SSL 3.0 as highest supported version.

This works only if the usage context is such that the client can attempt several connections (e.g. we are talking about HTTPS, with TCP connections that the client can open at will).

In practice, a server or a client usually supports a contiguous range of protocol versions (e.g. supports TLS 1.1 and 1.2, but not 1.0 or SSL 3.0). In that case, a single handshake attempt is sufficient: either the server will choose at the first try a protocol version which will be acceptable to the client, or there is no version which is acceptable to both client and server and it will never work.

Whether a given implementation of a SSL client offers an API to disable support of an old protocol version, is another question, of course.

  • Agree about contiguous range; as you wrote in security.stackexchange.com/questions/29314/… the record version containing ClientHello can suggest the minimum, although the RFCs do not require this. BUT for 1.2 in particular, if the client offers ONLY suites that use SHA2 or AEAD (GCM or CCM), a server that doesn't support and agree to 1.2 will be forced to reject. – dave_thompson_085 May 13 '14 at 10:29

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.