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).
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.
- 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.