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?
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:
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).ClientHello format, as long as that ClientHello message is a SSLv3+ ClientHello in disguise.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.
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.
When a client wants to send data to a server using SSL/TLS, a client must first go through a handshake to authenticate itself with the server. This handshake starts with the “ClientHello,” where the client sends to the server a version of SSL or TLS that it supports, the supported ciphers, and other session data. In older versions of SSL (version 2), it was possible to intercept this handshake packet and modify the supported ciphers list to only contain weak ciphers. This is no longer possible since SSLv3 uses a hash in the final part of the handshake, where both the client and server hash and compare sent and received messages.
All modern browsers support SSLv3 up to TLSv1.2, but will use the highest version supported by a server. A middleman cannot directly modify any packets sent in the handshake, but a middleman can intercept and drop certain packets. By tricking the browser into thinking that the server does not support a given version of SSL/TLS, an attacker can downgrade the negotiated version. You can see how it's done by visiting Praetorian's recent post: Man-in-the-Middle TLS Protocol Downgrade Attack
Why Move Away From SSLv3 Now?
While SSLv3 included special mitigations to prevent protocol downgrade attacks, it is not necessarily the ideal protocol to use. SSLv3 has significant cryptographic differences, which could result in weaknesses that further demonstrate why TLSv1.2 should be the current standard. The agreed-upon encryption and authentication ciphers, as well as key exchange mechanisms differed significantly in our protocol downgrade tests. In the above example, TLSv1.2 uses elliptic curve cryptography (ECC) along with counter mode for AES, while SSLv3 uses the older RC4 cipher and RSA.
Some may ask why this is necessary. In his 2013 Black Hat talk, Alex Stamos discussed the current state and future of cryptography. He argued that one of the dangers lies in the potential to break older ciphers or key exchange mechanisms at some point in the future. In the case of RSA, cryptographers and mathematicians have made significant progress in the problem of factorization. Diffie-Hellman (DH) relies on the discrete logarithm problem for cryptographic security, and while no efficient algorithm used to compute discrete logs exists, the runtime of discrete logarithm algorithms has significantly decreased in the past year. As Stamos discussed, once RSA or DH fails, code-signing will break, and attacks on SSL/TLS will become very prevalent.
In summary, an active attack on a connection can result in lowered cryptographic security. Clients and servers can prevent this from happening by supporting only newer versions of TLS. Additionally, clients should respond properly to failed handshakes. Currently, many browsers opt for interoperability over security, which makes protocol downgrade attacks feasible. These changes will require significant time and effort. Browsers would need to reimplement aspects of how they handle handshakes. Backwards compatibility may break in some instances. However, eventually we will need to require use of newer versions of TLS that support ECC. Why not make the push now, and prevent future attacks?
