SSL/TLS Protocol Version Negotiation
May 21, 2015 | POSTED BY STEVEN ANDERSON IN ENCRYPTION
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are cryptographic protocols that are designed to provide security for communications over a computer network. Theoretically, they establish a link through which to communicate securely. The protocols are only theoretically secure because the security is dependent on the following assumptions:
- First, it assumes that the certificates being used are legitimate. In other words, that the certificate in use has been signed by a legitimate, secure Certificate Authority (CA).
- Second, it assumes that the server or client has not been infected, thus compromising one or more of the endpoints.
- Lastly, it assumes that the protocol being used is a secure one, which is the focus of this post.
Using an SSL or TLS protocol is substantially more secure than not using one, but not all cryptographic protocols are created equal. For example, TLS is the new and improved version of SSL. It would have been unnecessary to produce a new protocol if SSL was sufficient.
The following is a list of the different cryptographic protocols in use historically:
- SSL 1.0 - Developed in 1993; only lasted one year; had inherent flaws: did not provide data integrity protection; if used with the RC4 cipher, was vulnerable to guided-guessing plain-text attacks; and was vulnerable to replay attacks.
- SSL 2.0 - Developed in 1994; was vulnerable to guided-guessing plain-text attacks; did not have protocol negotiation protection, allowing for man-in-the-middle protocol downgrade attacks; and was vulnerable to truncation attacks.
- SSL 3.0 - Developed in 1996; vulnerable to guided-guessing plain-text attacks; vulnerable to replay attacks on anonymous key exchange; and allows weak cipher suite options from SSL 2.0 as well as introducing strong options such as Diffie-Hellman.
- TLS 1.0 - Developed in 1999 and referred to as SSL 3.1; fixed cipher suite requirement issues from SSL 3.0 (forced Diffie-Hellman and Triple-DES); and shares some vulnerabilities with SSL 3.0 (replay attack and plaintext attack vulnerabilities).
- TLS 1.1 - Developed in 2006 with protection against cipher block chaining attacks implemented.
- TLS 1.2 - Current standard developed in 2008 with hash function MD5-SHA-1 combination replaced throughout the protocol with cipher-suite specified hash algorithms.
As observed in the above outline, each successive protocol was an improvement on the last. The reason TLS did not eliminate the use of SSL completely is the need for backwards compatibility. SSL 3.0 was in use by servers all over the Internet. Although it is far less prevalent, SSL 3.0 can still be found in use today. Due to the use of SSL 3.0 by older applications, servers that need to communicate with those applications maintain it as well. Due to the servers that maintain the use of SSL 3.0, browsers such as Internet Explorer still allow SSL 3.0 communication by default.
In order to decide what protocol to use, when the client side requests a secure connection it sends a "ClientHello" with the version number of the desired protocol (0x0300 for SSL 3.0, 0x0301 for TLS 1.0, etc). The server then responds with a "ServerHello" and the version number it is capable of using. For example, if the client requests 0x0302 for TLS 1.1 but the server is only capable of protocols up to TLS 1.0, it will respond with 0x0301. That leaves the connection decision up to the client. If the client's minimum protocol requirement is TLS 1.1, it will drop the connection as being insecure. Otherwise, it will downgrade to TLS 1.0 and establish the connection.
Although this allows for backward compatibility and prevents a lot of communication errors, it does present security risks. For instance, if a client's browser supports automatic protocol downgrades to SSL 3.0, it is possible for a man-in-the-middle attack to occur that forces the downgrade and allows for seemingly secure communication to be intercepted.