Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are protocols for maintaining a secure internet connection and protecting any sensitive data that is being sent between two systems.
SSL and TLS safeguard a connection between two endpoints (when configured correctly) and ensure that any data passed between users and websites, or between two systems, remains unreadable. These protocols do so by encrypting the data in transit, making it unreadable. Even though TLS 1.0 replaced the SSL protocol, the terms “SSL” and “SSL/TLS” are still frequently used interchangeably to describe these related technologies.
When TLS is used correctly, all an intruder should see when listening to network traffic is which IP and port are communicating with one another (but not the exact URL), how much data is sent, and what encryption and compression controls are being used. While the attacker can break the connection, both parties will know that it was broken by a third party.
SSL/TLS Protocol Explained
In a nutshell, the SSL handshake is a multistep process that begins once the browser or client completes the TCP (SYN/SYNACK/ACK) handshake. The SSL handshake message is then initiated by the client or browser a request for the server’s SSL certificate. The server responds with its SSL certificate, and the browser verifies the certificate. If the certificate is valid, the browser then creates a random key and encrypts it with the server’s public key. The browser then sends the encrypted key to the server. The server decrypts the key with its private key and uses the key to encrypt the HTTP response. The browser decrypts the HTTP response with the key and displays the HTML page.
The diagram below illustrates this process with a more detailed description of the steps following it.
The TLS handshake is composed of two main phases: the TLS Record Protocol and the TLS Handshake Protocol.
The TLS Record Protocol is responsible for encapsulating application data into records that can be securely transmitted over the network. The TLS Record Protocol uses a variety of different encryption algorithms to protect the data, depending on the security parameters negotiated during the TLS Handshake Protocol.
The TLS Handshake Protocol is responsible for negotiating the security parameters between the client and server. The TLS Handshake Protocol is composed of a series of messages exchanged between the client and server. The messages are broken down below:
- ClientHello: The first message in the TLS Handshake Protocol is the ClientHello. The ClientHello message contains a list of supported cipher suites and compression methods. The client also includes a random number, which is used to generate the session keys.
- ServerHello: The second message is the ServerHello. The ServerHello message contains the server’s chosen cipher suite and compression method. The server also includes a random number, which is used to generate the session keys.
- Server’sCertificate: The Certificate message contains the server’s public key, which is used to verify the server’s identity.
- ServerKeyExchange: The ServerKeyExchange message contains the server’s Diffie-Hellman public key, which is used to generate the shared secret key.
- Certificate Request: If mTLS (mutual TLS) is enabled, the server will authenticate the client by requesting a certificate.
- ServerHelloDone: Zero-length marker message sent from the server indicating that it is finished and that the client should now talk.
- Client’s Certificate: If requested by the server, the client will supply it’s own certificate to the server.
- ClientKeyExchange: The ClientKeyExchange message contains the client’s Diffie-Hellman public key, which is used to generate the shared secret key.
- CertificateVerify: The CertificateVerify message is used to verify the certificate.
- Change Cipher Specifications: The ChangeCipherSpec message is used to notify the client and server that the handshake messages will be encrypted using the newly negotiated security parameters.
- Finished: The client and server successfully finish the handshake.
How to Secure SSL
Here are few key tips (based on OWASP recommendations) to keep in mind when configuring SSL on a server:
- Use TLS everywhere you can: If possible, TLS should be used for all pages with HTTP disabled. If not, TLS and non-TLS content should not be mixed and HSTS enabled.
- Use a strong protocol: SSL is a protocol that is used to encrypt communication between two parties. There are a few different versions of SSL, and the newer versions are more secure than the older ones. Supporting only the latest most secure protocol is recommended (TLS 1.3) with older versions only enabled when necessary.
- Use strong ciphers: Ciphers are the algorithms used for encryption. The stronger the cipher, the more secure the connection. Some ciphers are much weaker than others and their support should be avoided. Ciphers should use strong Diffie-Hellman parameters.
- Disable compression: When TLS compression is not disabled, it is vulnerable to the CRIME vulnerability.
- Keep libraries and software up to date: OpenSSL and other software components used for SSL have older versions with known vulnerabilities. As with all other software types, it is recommended they be kept up to date.
- Use a strong certificate: A certificate is like a digital ID. It is used to verify that a site is who it says it is. A weak certificate can be easily forged, so it is important to set up certificates correctly by following steps such as:
- Using a trustworthy Certificate Authority and never using self-signed certificates
- Using strong keys and securing private keysUsing strong hashing algorithms in the certificate
- Correctly configuring domain names in the certificate
- Avoiding the usage of wildcard certificates
- Using Certification Authority Authorization (CAA) DNS records to restrict which CA is allowed to issue certificates
- Use public key pinning: Public key pinning is a security measure that involves specifying a set of trusted public keys in advance, and then checking for those keys when connecting to a server. This helps to prevent man-in-the-middle attacks, by ensuring that the server’s public key is always the one that is expected.
SSL/TLS Versions
The main difference between SSL versions is the level of security they offer. SSL protocols versions 2 and 3 are the weakest and oldest protocols, offering only basic security features, while TLS 1.0 and 1.1 are stronger, offering better encryption and data integrity albeit still considered insecure by today’s standards. TLS 1.2 and 1.3 are even stronger, offering improved security features and greater compatibility with newer browsers and devices. The details for each version are below:
SSL 1.0:
Due to significant security issues in the protocol, SSL version 1.0 was never made available to the general public.
SSL 2.0:
After it was deployed in February 1995, SSL Version 2.0 was rapidly found to have a number of security and usability problems. The security flaws were vast. For instance, it didn’t offer any protection for the formal handshake or the closing message, which allowed man-in-the-middle assaults to succeed unnoticed. Furthermore, b oth message encryption and message authentication utilized the same cryptographic keys. It was susceptible to length extension attacks because it had a weak MAC design and used the MD5 hash function with a secret prefix. IETF’s RFC 6176 deprecated SSL 2.0 in 2011.
SSL 3.0:
The IETF released SSL 3.0 in RFC 6101 to address the security issues with SSL v 2.0. All SSL block ciphers are susceptible to the POODLE attack, which was discovered to impact SSL 3.0 in 2014. It is also conceivably broken for SSL 3.0 to utilize RC4, the sole non-block encryption supported by SSL 3.0.
RFC 7568 deprecated SSL 3.0 in June of 2014
TLS 1.0:
TLS 1.0 was initially described as an improvement to SSL Version 3.0 in RFC 2246 in January 1999. Due to numerous security flaws such as BEAST and POODLE, TLS 1.0 was formally deprecated in March 2021.
TLS 1.1:
TLS 1.1, an update to TLS version 1.0, was described in RFC 4346 in April 2006. This version has improved defense against cipher-block chaining (CBC) attacks, among other significant changes. However, TLS 1.1 was found to be vulnerable to the same downgrade attacks as TLS 1.0 since they both rely on SHA-1 hash for the integrity of exchanged messages. TLS 1.1 was formally deprecated by IETF as of March 25, 2021
TLS 1.2:
TLS 1.2 was defined RFC 5246 in August 2008. It is considered to be a secure version of TLS at the time of this writing.
TLS 1.3:
TLS 1.3 was defined RFC 8446 in August 2018. It is considered to be a secure version of TLS at the time of this writing.
