What version of TLS does any web browser use when connecting to server where all SSL Protocols are enabled?

Question

All (almost all) web browsers have TLSv1.0 enabled by default, moreover TLSv1.1 and even TLSv1.2 can also be enabled by default.

What version of TLS will be used to connect to web server (e.g. Apache) with all SSLProtocol enabled?

What order of protocols will be used for browser with TLSv1.0-1.2 enabled by default?

For instance, we have a server with all protocols enabled (SSLv3, TLSv1, TLSv1.1 and TLSv1.2). Our browser has TLSv1.0, TLSv1.1 and TLSv1.2 enabled by default. What protocol will be used during first connection to server?

The same situation, but our web server has TLSv1.2 disabled. What will be browser behavior?

Answer 1

The theory, as exposed in the standard is that:

server_version

   This field will contain the lower of that suggested by the client
   in the client hello and the highest supported by the server.

In the ClientHello message, the client announces a single version, and this means "I support all versions up to that version". For instance, if the client says "TLS 1.1" then the client is somehow promising that it can handle SSL 3.0, TLS 1.0 and TLS 1.1. The server is then supposed to pick the most recent protocol version that both client and server support.

However, client implementations know that we do not live in a perfect world, and some servers get it wrong sometimes, so they do connections in a loop. For instance, the client first announces "TLS 1.2", but if the handshake fails for some reason which might be due to flaky support by the server, the client may try again, announcing only "TLS 1.1" or "TLS 1.0". Not all clients do that, but this is common for Web browsers. As @dave explains, a TLS 1.2 ClientHello may be larger than a previous version and make poorly written servers trip on it, so the "try again with a lower version" behaviour is, alas, necessary.

As explained above, the client only announces a range, so the client cannot express a support "with holes", e.g. supporting TLS 1.0 and 1.2 but not 1.1 (not that it makes a lot of sense). Similarly, the client sends both its "maximum supported protocol version" and its ordered list of supported cipher suites, so the client cannot express in a single ClientHello a preference such as: "let's do TLS 1.2 and AES-CBC, but if we have to use TLS 1.0 then I would prefer RC4 because I am in mortal fear of the BEAST attack". If a client wants to enforce such preferences, then it must do the "multiple connections" trick.

To sum up, the normal paradigm of SSL is: the client suggests, the server chooses. But if the client wants to force the server into using some specific protocol version and/or cipher suite, then it can, through re-connections, and existing Web browsers do play such games occasionally.

Answer 2

Although some SSL clients (including browsers) and servers can be configured to enable or disable protocol versions, there is no preference order. The ClientHello message states only the highest version offered (although the record-layer version is sometimes used to suggest the lowest); the ServerHello message can choose any version <= the client's offer, and should be the highest version supported by both. If the client's offered maximum is too low for the server, the server should fail the handshake, and if the server's choice is too low for the client, the client should do so. See What is the significance of the version field in a TLS 1.1+ ClientHello message? .

Note that either side may decide to do less than it can. For example, Java 7 (SunJSSE) implements TLS1.2 but client by default only offers 1.0 because Sun^WOracle perceived too much risk of problems; and Java 6 client by default used SSLv2 format with offered version 0301 so server could choose SSLv3 or TLS1.0, but if server agreed to SSLv2 (which is way obsolete and badly insecure), client failed the handshake with a specific exception "SSLv2 is insecure" instead of just "bad response" as would have happened for SSLv3+ hello to SSLv2-only server. In contrast OpenSSL 1.0.1 implemented TLS1.2 (and 1.1) and client by default now offers 1.2, which quickly caused a rash of complaints on the mailing lists about servers that suddenly failed on the 1.2 ClientHello, which is significantly larger because of the larger default cipherlist plus some new extensions, resulting in a rash of often ugly workarounds.

Ciphersuites are listed in order as Rubber Duck describes, although the server is not required to honor that order and some don't. So are elliptic curves (sometimes important), elliptic point formats (rarely important), and compression algorithms (rarely implemented and often undesirable due to CRIME type attacks). But note the entire handshake, including the ciphersuite list, is protected from tampering including downgrade since SSLv3 by the Finished exchange -- unless you cheat in an attempt to improve performance e.g. https://datatracker.ietf.org/doc/html/draft-bmoeller-tls-falsestart-00 (which mostly failed for other reasons though). But clients -- or even users -- may voluntarily downgrade themselves if the attacker just simulates server error(s).

Answer 3

As part of the handshake, the server ends up choosing the cipher that is chosen.

Per RFC 5246, the client (browser) sends a list of what versions of ciphers it supports. The server then picks which one it wants to use. Generally, it will go for the most up-to-date cipher. However, one cool idea of man-in-the-middle attacks is to downgrade the supported cipher list on the initial client hello message.

More can be read on TLS Cipher Suites, but the summary is this:

When a TLS connection is established, a handshaking, known as the TLS Handshake Protocol, occurs. Within this handshake, a client hello (ClientHello) and a server hello (ServerHello) message are passed. (RFC 5246, p. 37) First, the client sends a cipher suite list, a list of the cipher suites that it supports, in order of preference. Then the server replies with the cipher suite that it has selected from the client cipher suite list. (RFC 5246, p. 40) In order to test which TLS ciphers that a server supports an SSL/TLS Scanner may be used.