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

  • 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?

    Depends on the internal priority of each browser as well as the browser's version.

    Servers and browsers will usually prefer the highest TLS version that is mutually supported and activated. If both support TLSv1.1 and nothing higher, then in the vast majority of cases, the connection will use TLSv1.1.

    You can configure the order of preferred protocol/cipher in the web server config. It would depend on which you set as preferred.

  • Tom Leek

    Tom Leek Correct answer

    7 years ago

    The theory, as exposed in the standard is that:

       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.

    Just as an update, but it turns out there are several possible attacks on SSL/TLS using downgrade during handshake, and nowadays if you want your server to be considered reasonably secure you configure it to reject handshake downgrading.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used