Essay: SSL vs TLS

Summary
Introduction
Background
Secure connections in the time that we live is vital due to the vast number of people who transfer data that is private online, for example, shopping and entering card details. The way that these connections are established is just as important, as a flaw in establishing the connection can lead to the data being intercepted and worse, decrypted.
Both SSL and TLS are used nowadays to establish a secure connection, however SSL has had multiple successful attacks launched against it with severe data leaks and so it is less secure than once thought. Due to this, TLS is being developed rapidly to eventually take the place of SSL.
TLS is often referred to as SSL v3.0, however this was due to the first version of TLS being so similar to SSL. This is not the case anymore and any references to TLS throughout will be clearly labelled with the version number, for example TLS v1.0 or TLS v1.3.
Aim
The aim of this project is to research the similarities and differences between SSL and TLS, including how they secure a connection and network traffic.
Objectives
To meet the aim above, it is necessary to meet the following objectives:
1. Understand what SSL and TLS are and how they operate
2. Understand the similarities and differences between SSL and TLS
3. Understand why TLS was created
Methodology
To meet the above aims and objectives, the following steps must be followed:
1. Research SSL and how it operates
2. Research TLS and how it operates and understand why it was created
3. Look into different versions of TLS
4. Find the differences between SSL and TLS
5. Look into where they would be used together/separately
Due to the nature of the topic, it is fully research based as it aims at looking at protocols used to establish connections.
Findings
SSL
SSL (Secure Socket Layer) has been used for many years to secure connections and it has stood up to the strain that it has been under for most of that time. It does this with the use of Public and Private keys and a Certificate.
A server that is using SSL must have a Certificate attached to it which can be self-signed or signed by a Certificate Authority (CA), who will validate the data in it and add it to a trusted list. A Certificate will hold information about the website and company that it is being assigned to, this can include the name of the company and website that it is authorised for, but the most important data that it contains is a pair of Public and Private keys.
When a SSL connection is to be established, it goes through what’s known as a SSL Handshake (see Figure 1), which is much like the TCP Handshake (which must be done before the SSL Handshake), in that it verifies that the server and client (generally a web browser) are both connecting and listening.
Figure 1. SSL Handshake (Digicert.com)
The steps of a SSL Handshake are as follows:
0. A TCP Handshake must first occur as the transmission of data is important and using UDP would be impractical as it operates on a connectionless protocol.
1. After the TCP Handshake, the SSL Handshake can commence. It first starts with the client requesting a copy of the server’s certificate. This is important as it contains the server’s public key.
2. Once the server receives a request from a client, it will reply with the certificate requested.
3. After receiving the certificate, the client will check to ensure that it is valid. This includes checking if:
− the CA that issued the certificate is trusted
− the certificate is expired or revoked
− the domain it is registered to is for the domain that it is being used in
and should all be valid, a session key (which is used to encrypt all data between the client and server) is generated and encrypted with the public key and then sent to the server.
However, if any of the checks return false, then the user is warned to let them know that the connection is not private and is using HTTP, or in the case of a certificate being self-signed, the user is warned of this but the connection may still be using HTTPS.
4. The server then decrypts the received session key using its own private key and replies with an acknowledgement that is encrypted with the session key, and now it knows that the connection is secure.
5. After receiving the acknowledgement, the client now knows that it is connected securely to the server and data transmission now begins.
Note that Public and Private Keys are asymmetric, meaning that they are both different, otherwise the connection and protocol as a whole would not be secure. However, the session key that is generated in stage 3 is symmetric, meaning that both the client and the server have the same session key shared between them and it is just encrypted in transit which still makes it secure unless an attacker has control of one of the systems.
TLS v1.0
Transport Layer Security (TLS) v 1.0 was first developed in 1999 after fears that SSL was less secure and could therefore not be used for sensitive information. But since the POODLE attack on SSL (the attack made use of SSL’s encrypt then authenticate sequence, which encrypts traffic before the receiver has been authenticated. During the encryption process, the final byte of a packet is padding, however SSL doesn’t specify what has to be in the padding therefor attackers can use this to their benefit to decrypt information byte-by-byte, most commonly a cookie) the development of TLS has increased as it aims to take over from SSL and the newest version is set to be released, v1.3, and is currently used in Googles Canary version of Chrome.
TLS v1.0 establishes a secure connection in a similar way to SSL and it still makes use of Certificates. It uses a TCP connection to establish an initial connection between client and server and then performs a TLS Handshake (see Figure 2).
Figure 2. TLS v1.2 Handshake (blog.cloudflare.com)
The steps of a TLS v1.0 (Figure 2 is the TLS v1.2 handshake, however the handshake has remained the same since v1.0) handshake are:
0. Just as with the SSL Handshake, a TCP Handshake must be successful before any data relating to TLS Handshake can be sent.
1. Once the TCP Handshake is finished, the client will send information to the server in plaintext, also known as a “Client Hello”, which will include the version of TLS that the client is running and a list of available cipher-suites that it supports. This being sent in plaintext means that it can be intercepted and read by an attacker, however there is no private or exploitable information transmitted in the Hello
2. Once the server has received the Hello from the client, it chooses a TLS version (TLS versions are backward compatible, so should the server be running TLS v1.2, and the client is using TLS v1.1 or 1.0, it will still work) and a ciphersuite to use. It then sends this information along with a copy of its Certificate to the client. This information that is sent is called the “Server Hello”.
3. Once the client receives the Server Hello, it will check the Certificate to ensure that it is still valid. It checks for the same items as in the SSL Handshake. The client should automatically agree with the TLS version and ciphersuite returned by the server as the server chose from the information given in the Client Hello, however if there is an issue then the sequence goes back to step 1 and the client will send another Hello.
If the Certificate is valid, then the client will initiate the Key Exchange, using either RSA or Diffie-Hellman, which generates a symmetric session key for this session and then sends the session key to the server, encrypted with the Public Key given in the Certificate.
4. Once the server has received the key, it will verify the MAC sent by the client, and if all checks out and is correct then it will send an encrypted FINISHED message to the client.
5. After the client has received the encrypted message, it will verify the MAC sent and if it is correct, decrypt the message and if it is as expected (a FINISHED message) then the client knows that the connection to the server, and vice versa, is secured with TLS and data transmission can begin.
As can be seen, the SSL and TLS v1.0 handshakes are very different, even though they still use Certificates. However, TLS v1.0 has been found to be vulnerable, as have versions 1.1 and 1.2, so version 1.3 has been created and is set to be officially released this year (and is currently supported by many big companies, for example Cloudflare, Google with their Chrome Canary browser and Firefox with their Nightly browser).
TLS v1.3
TLS v1.3 offers vast differences between the previous versions, as well as still being backwards compatible, and has increased the security and speed of the handshake greatly.
Increased Security
TLS v1.3 has removed support for broken encryption methods. These include:
– RSA Key Transport as it has no support for “Forward Secrecy”, the act of ensuring that past keys are not able to be used to decrypt future transmissions by generating a new public key for every connection made, whether it is new or old. TLS v1.3 now prefers ECDHE (Elliptical Curve Diffie-Hellman Exchange) as it supports Forward Secrecy and a server that uses ECDHE and TLS v1.3 are also what is known as ephemeral, which means that the keys are erased after a connection has ended.
– SHA-1 hash function after the recent collision released where two different PDF files revealed with the same hash. Instead SHA-2 is preferred when using TLS v1.3
There are multiple other methods removed, but the above two were the most commonly used. But with the removal it means that any attacks on previous version of TLS (which support the encryption methods) will be a lot less likely to work on TLS v1.3. It also means that the TLS protocol is faster to operate and create a handshake.
Increased Speed
In previous versions of TLS, the protocol required two round-trips (requests from client to server and back to client) before a page could be requested by the client. However, because of optimization and the removal of the older and less secure encryption methods, it can request a page after the first round-trip
Summary
Differences Between SSL and TLS v1.3
As mentioned earlier, SSL and TLS are both used to secure a connection between client and server, however they both do this differently and with TLS being more secure and robust. In summary:
SSL v3.0
TLS v1.3
Uses encrypt then authenticate when establishing a connection
All data is encrypted with a session key from the first request to the server
Requires multiple round-trips before page can be requested
After the first round-trip the page can be requested from the server
Less secure as still has support for more vulnerable ciphersuites, e.g RSA and SHA-1
Removed vulnerable ciphersuites
Vulnerable to fall-back requests (Poodle attack to force SSL v2.0)
Support backwards compatibility but is less likely to be affected by past vulnerabilities
Still susceptible to MITM attacks
MITM attacks shouldn’t work with TLS v1.3 as every request/message sends a MAC which is verified at each end
Conclusion
References