The question is that, what if the client only supports TLS 1.1 and the server has TLS1.2 or SSL 3.0 enabled. Will it then go back to SSL 3.0 because the server doesn’t have TLS 1.1 enabled?

  • SSL 3.0 could be configured as a fallback. The client can also give up and echo ERR_SSL_VERSION_OR_CIPHER_MISMATCH (or friends) – Yorick de Wid Sep 9 '16 at 15:15
  • Think of supported TLS versions as a bitmask. AND the bitmask of the client and the server and the highest bit set (corresponding to the most modern version) will work. Eg if the server only has TLS 1.2 and SSL 3.0 and the client only TLS 1.1, the connection will fail. – SEJPM Sep 9 '16 at 15:15

In the SSL/TLS handshake, things go thus: the client sends a maximum supported version; then the server chooses the version that will be used, and sends it to the client.

The server, by definition, won't choose a protocol version that it does not support. The server will try to select a version that it supports and that is also supported by the client; however, the server has only partial information about what the client supports, since it only received a "maximum supported version". If the client says "up to TLS 1.1", then the server knows that the client supports TLS 1.1 (or least claims to) but not TLS 1.2; whether the client would support/accept TLS 1.0 or older protocol versions is unknown to the server at that point.

In your envisioned situation, if the server supports only TLS 1.2 and SSL 3.0, then it will select only TLS 1.2 or SSL 3.0. If the client says "I support up to TLS 1.1", then the server will not select TLS 1.2 (since, at this point, the server knows that the client does not support it); therefore, it will choose SSL 3.0, which is its only other choice. The client, upon receiving that answer from the server, may very well say "SSL 3.0? What sort of antique server is that? Why not flint stone tools while we're at it?" and refuse to communicate any further.

Basically, for the handshake to succeed, there must be a protocol version that both client and server support. If the client supports only TLS 1.1, and the server supports only TLS 1.2 and SSL 3.0, then there is no common protocol version, and communications won't happen.

Now there may be weird situations in which client and server fail to notice that they do have a version that they both support. For instance, the client, for some reason, supports TLS 1.0 and 1.2, but not TLS 1.1; and the server supports TLS 1.0 and 1.1, but not TLS 1.2. In such a situation, the client will claim to support "up to TLS 1.2", and the server, who knows only TLS 1.0 and 1.1, will choose TLS 1.1, that the client will reject.

In practice, such situations do not occur, because implementations don't have "holes" in the range of protocol versions that they support. If a client or server supports versions X and Y, then it will also support all versions between X and Y. It makes very little sense to support TLS 1.0 and TLS 1.2 but not TLS 1.1.

  • The Oracle/OpenJDK implementation JSSE, although it defaults to a sane version range, can easily be set by careless code or config to have such 'holes' with troublesome results as described. (IBM Java has different cryptoproviders and I don't know if the same is true there.) Also there was an informal custom to put minimum version in record-header (versus maximum in ClientHello body) which is codified as MAY-but-no-guarantees in rfc5246 E.1. – dave_thompson_085 Sep 10 '16 at 7:29
  • apache allows settings holes: httpd.apache.org/docs/current/mod/mod_ssl.html#sslprotocol nginx also allows setting holes: nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols – Z.T. Oct 9 '16 at 0:59

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.