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?