Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

If I click on the little lock icon in Chrome it says that the site in question is using TLS v1. I also checked using openssl and was able to hit the site using TLS1, SSL2 and SSL3. From what I understand SSL2 is not secure. Based on this, it appears that the site could be hit using any of the three.

What determines the version of SSL/TLS that will be used when accessing a secure site from a web browser?

share|improve this question

2 Answers 2

up vote 7 down vote accepted

As @Terry says, the client suggests, the server chooses. There are details:

  • The generic format of the first client message (the ClientHello) indicates the highest supported version, and implicitly claims that all previous versions are supported -- which is not necessarily true. For instance, if the client supports TLS 1.2, then it will indicate "max version: 1.2". But the server may then elect to use a previous version (say, TLS 1.0), that the client does not necessarily want to use.

  • Modern clients have taken to the habit of trying several times. For instance, a client may first send a ClientHello stating "TLS 1.2", and, if something (anything) fails, it tries again with a ClientHello stating "TLS 1.0". Clients do that because there are poorly implemented, non-conforming TLS servers who can do TLS 1.0 but reject ClientHello messages that contain "TLS 1.2".

    An amusing consequence is that an active attacker could force a client and server to use an older version (say TLS 1.0) even when both support a newer protocol version, by forcibly closing the initial connection. This is called a "version rollback attack". It is not critical as long as client and server never accept to use a definitely weak protocol version (and TLS 1.0 is still reasonably strong). Yet this implies that a client and server cannot have a guarantee that they are using the "best" possible protocol version as long as the client implements such a "try again" policy (if the client did not implement such a "try again" then the rollback attack would be prevented, but some Web sites would become seemingly unreachable).

  • The ClientHello message for SSL 2.0 has a very distinct format. When a client wishes to support both SSL 2.0 and some later version, then it must send a special ClientHello which follows the SSL 2.0 format, and specifies that "by the way, I also know SSL 3.0 and TLS 1.0". This is described in appendix E of RFC 2246. Modern SSL clients (Web browsers) don't do that anymore (I think IE 6.0 still did it, but not IE 7.0).

    RFC 4346 (TLS 1.1) specifies that such SSLv2-format ClientHello messages will be "phased out" at some point and should be avoided. RFC 5246 (TLS 1.2) more clearly states that clients SHOULD NOT support SSL 2.0, and thus should have no reason to send such ClientHello messages. RFC 6176 now prohibits SSL 2.0 altogether.

    Now a RFC is not a law: you don't go to jail because you don't support any particular RFC. However, RFC still provide guidance, and thus somehow illustrate what will be the state of things in the near (or far) future.

In practice:

  • Most clients out there will send only SSLv3+ ClientHello messages, and will happily connect with SSL 3.0, TLS 1.0, TLS 1.1 or TLS 1.2, depending on what the server appears to support (but, due to the "try again" policy, a version downgrade can be forced upon by an active attacker).
  • Actually, some clients won't support SSL 3.0, and require TLS 1.0.
  • Similarly, some clients won't support TLS 1.1 or 1.2. Web browsers have been updated in the recent years (in the aftermath of the bad press resulting from the BEAST attack) but non-browser applications are rarely as aggressively maintained.
  • Many server still accept a SSLv2 ClientHello format, as long as that ClientHello message is a SSLv3+ ClientHello in disguise.
  • A few servers, like yours, are still happy to do some SSL 2.0. This does not conform to RFC 6176, and is frowned upon (people who believe in "grading SSL servers" will give you a bad score for that). This is not a serious security issue, though, as long as clients don't actually support SSL 2.0. Even if a client supports SSL 2.0, it should include some rollback-prevention trickery (described in RFC 2246) so a rollback down to SSL 2.0 should not work.

You still want to deactivate SSL 2.0 support in your server (not necessarily SSLv2 ClientHello format, but actual SSL 2.0 support), if only for public relations.

share|improve this answer

You should read up on the TLS handshake process.

To briefly summarize, the client (which in this case is the browser) sends a ClientHello message to the server. This contains the maximum TLS version it supports as well as a list of cipher suites it supports in order of preference. The server than decides which TLS version and cipher suite it wants to use for the TLS connection and informs the client by replying with a ServerHello. Ideally the highest TLS version and strongest cipher suite should be selected, but the TLS specification does not guarantee this. The server is free to use whatever it wants out of the list provided by the client.

share|improve this answer
    
In addition, it's browser, and sometimes OS specific. Windows Sockets have a configuration for Schannel that controls what's permitted during negotiation. –  makerofthings7 Jun 4 at 17:49
    
Very interesting thank you. Do you happen to know what the latest browser/version to send SSL2 as it's preferred version was or where I could find that info? –  Abe Miessler Jun 4 at 18:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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