Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are two cryptographic protocols used for providing secure communication over a network. The Internet Engineering Task Force (IETF) prohibited the use of SSL which led the way for TLS to succeed it. The protocols have several variations and iterations used in web browsing, email, Internet faxing, instant messaging, and voice over IP (VoIP). Websites, in particular, are known for using TLS for securing communications between their servers and web browsers. This is accomplished by TLS providing privacy and integrity to data between two communicating nodes on a network.

Functionality and Usability

When a connection is secured by TLS, it acquires one or more of the following properties:

The connection can become private (or secure) because symmetric cryptography is used to encrypt data before transmission. The keys for this encryption are generation on a per-connection basis and are designed on a “shared secret” which was negotiated at the inception of the session.

Another property is having one of the parties in the communication be identified by using public-key cryptography. This is usually the server and is optional although it's generally required for one of the parties to be identified like this.

Message authentication codes attached to each message can ensure message integrity. This overall means that the entire connection will have integrity. The protocol itself is divided into two layers; the TLS record, and the TLS handshake. TLS records are encapsulated data which are to be exchanged in a specified format. Records can be compressed, padded, appended with a message authentication code (MAC), or encrypted depending on the connection's status. They each have a content type field which describes what type of data is encapsulated, a length field, and a TLS version field. The specifications of which are required to exchange the application data by are decided upon during the TLS handshake. This means that the protocol basically defines the structure of payloads to be transmitted and the process involved in establishing and monitoring the transaction.

A TLS handshake is initiated when a connection is established by the record encapsulating the handshake messaging protocol (content type 22). This protocol is then used to transmit all information required by both parties in the connection for the exchange of the actual application data. In this process, the format of messages and the order of their exchange is defined and may vary depending on the demands of the server and client; such as there being several different procedures involved to establish a connection. This initial exchange will either result in a created TLS connection or an error message.

There exists two types of handshakes. A basic TLS handshake is completed when the server is authenticated by its certificate.

• Firstly, at the negotiation phase, the client sends a ClientHello message to the server and waits for acknowledgement. This message will usually entail the highest version of TLS it can support, a list of suggested cipher suites and congestion methods, and a random number. If the client is instead trying to resume a handshake, it may contain the session ID for that handshake. If the client can use Application-Layer Protocol Negotiation, it may also include a list of application protocols it supports such as HTTP/2.
• The server will acknowledge the client with its own ServerHello message which will contain the chosen TLS version number (typically, the highest version both the server and client supports), a cipher suite and compression method from the client's suggestions, and a random number. If the client sent a session ID, the server will instead confirm or allow a resumed handshake by sending back the session ID.
• This will then be followed by another message by the server which will contain its Certificate (this step may or may not be omitted depending on the chosen cipher suite).
• Next, the server will send another message which will contain its ServerKeyExchange (this step may or may not be omitted depending on the chosen cipher suite).
• Finally, the server will send another ServerHelloDone message to indicate it is finished negotiating.
• The client will then respond with a ClientKeyExchange message which may contain a PreMasterSecret, a public key, or nothing at all. In the case of a PreMasterSecret, it is encrypted by the public key of the server certificate (this step is dependent on the chosen cipher suit).
• The client and server then use the random numbers and the PreMasterSecret to create a “shared secret” and all other key data for the duration of the connection is created using this and the associated random numbers from both the client and server.
• The client sends a ChangeCipherSpec record which notifies the server that from now on, all messages it relays will be authenticated (and encrypted if that was a part of the negotiation parameters). This record is actually a record-level protocol of content type 20.
• Finally, the client will send an encrypted Finished message which contains a hash and MAC for the previous messages.
• The server decrypts this message and verifies the client's hash and MAC. If the decryption or verification fails, the handshake is considered a failure and the connection should be disconnected.
• After successful decryption and verification, the server will respond with its own ChangeCipherSpec record with the same meaning as the client's.
• The server sends the client their own encrypted Finished message which the client will then decrypt and verify. Failure of this should also have the same result of considering the handshake a failure and dropping the connection.
• At this point, the connection reaches the application phase as the handshake is now completed and the application protocol is enabled with content type 23. The application data can then be exchanged between the two and could optionally be encrypted in the same way as with their respective Finished messages. Otherwise, the content type will change to 25 and the client will not authenticate.

The other method for a performing a TLS handshake is the client-authenticated TLS handshake. In this version, the client must also be authenticated after the server followed the above process by the two sending certificates between each other. As such, the only difference between these two modes is that after server sends its ServerHelloDone message, the client will send its Certificate and after the client's ClientKeyExchange message, they will send a ClientVerify message. This message is signifies agreement with the previous messages thus far and is made by the client's private key. By doing this, the client tells the server that the certificate is theirs because they have the private key and it can be authenticated by using the client's public key.

It should also be noted that a session ID is sent in each client's ClientHello message to uniquely identify the handshake. This ID is linked to the server's IP Address and TCP port by the client so that it can easily reconnect to the server if resuming the handshake. This process is considered much faster and optimal as public key operations are more expensive and it avoids such a process. On the server's end, the session ID is mapped to the “shared secret” and both the client and server must have the same “shared secret”; otherwise, the handshake will fail. This type of handshake could also be called an abbreviated handshake or a restart handshake. This handshake is identical as well to the aforementioned basic handshake with the exceptions that the servers ServerHello message has some additional functionality to it. When the server receives the session ID from the client and compares it, if it does not recognize the ID, the server will reply with a different value to notify the client that a restart handshake will not be performed. On the other hand, if it is successful; the process will immediately jump to the ChangeCipherSpec message step as both the server and client will have the “shared secret” and random data to proceed.

Another means of storing a session ID is a session ticket which allows a TLS client to store the information and not rely on the TLS server to hold it. This is what the client would use to restart a handshake. It should be noted however that the encryption of this ticket is limited with OpenSSL making it not as secure as the actual session itself.

Security and Improvements

SSL 1.0, 2.0, and 3.0 were all developed by Netscape. In truth, version 1 was never released because of serious security flaws but version 2 was flawed in a variety of ways as well. It allowed identical cryptographic keys to be used for both message authentication codes and encryption, has a weak MAC construction, offers no protection for its handshake process, was vulnerable to truncating attacks if an attacker used the TCP FIN command, and because it assumes a single service and a fixed domain certificate which clashed with virtual hosting capabilities in web servers, most websites were impaired from using it. The version is now disabled by default in most web browsers because of this.

Version 3.0 sought to improve on version 2.0 with the addition of SHA-1 based ciphers and support for certificate authentication but it was still inferior to TLS v1.0. Its cipher suites were weaker and half of the “shared secret” was fully dependent on the MD5 hash function which is not secure.

On the other hand, TLS v1.0 had a vulnerability in it which allowed an attacker to downgrade the protocol to SSL v3.0 (a rollback attack). Version 1.1 improved its predecessor's security by adding protection against cipher block chaining (CBC) attacks. Version 1.2 improved the security even more by replacing MD5-SHA-1 hashes with SHA-256 hashes whenever used and adding overall improvement with cipher suites used. At the moment, there is a draft for v1.3 which seeks to improve the security even further by removing support for MD5 and SHA-224 hashes, removing weaker and lesser-used elliptic curves, and more.

Still, regardless of all the improvements made, the type of problems the TLS protocol face still need to be outlined as not all of them have a solution just yet. A renegotiation attack can be done by an attacker capable of hijacking Hypertext Transfer Protocol Secure (HTTPS) connections to splice their own requests at the early stages of the handshake. This means that the attacker doesn't have to actually decrypt the messages so it's somewhat different from the usual man-in-the-middle attack. To counter this, a renegotiation extension was implemented which requires the client and server to provide information about previous negotiations.

A protocol downgrade (or rollback) attack tricks the server into agreeing to using an older and insecure version of the protocol (usually SSL v2.0) to take advantage. Some previous modifications (such as False Start or Snap Start) allowed for this vulnerability by allowing modifications to the cipher suit suggestion list sent from a client to the server. Through this, attackers would trick the server into using weaker cipher suites to take advantage of a weaker symmetric encryption algorithm or key exchange.

A DROWN attack is an exploit which targets servers supporting TLS/SSL contemporary protocol suites by forcing them to use SSL v2.0. The attacker then takes advantage of the exploits within the SSL v2.0 protocol instead of trying to find any faults with the configuration of the server itself. In 2016, when the attack exploit was announced, there was a patch to fix this.

A Browser Exploit Against SSL/TLS (BEAST) attack was demonstrated by Thai Duong and Juliano Ruzzo in 2011, which used a Java applet to violate same origin policy constraints through a long-known CBC vulnerability in TLS v1.0. The vulnerability was later fixed with other variations of the protocol such as Rivest Cipher 4 (RC4) which was immune to the attack. Chrome and Firefox are also not vulnerable to the attack; however, Microsoft and Apple both had to do security updates to their operating systems to prevent. Duong and Ruzzo were also the creators of the CRIME attacks, which allowed an attacker to recover the content of web cookies whenever data compression was used with TLS, and BREACH attacks, which could extract sensitive information from the procured cookies through exploiting HTTP compression. At the moment, while CRIME attacks can be mitigated by turning off TLS and SPDY compression, BREACH attacks are still possible on all versions of TLS and SSL as there's no real way to turn off HTTP.

Earlier versions of TLS were also vulnerable to padding oracle attacks but when v1.2 was released, the attack was possible to be mitigated. The attack used the padding validation of a cryptographic message for decryption. A Padding Oracle on Downgraded Legacy Encryption (POODLE) attack is built upon this by manipulating a vulnerability in SSL v3.0. this allowed attackers to, on average, issue 256 SSL v3.0 requests to reveal one byte of encrypted messages. Despite the vulnerability was on SSL v3.0, many websites still use TLS v1.0 and voluntarily downgrade to SSL v3.0 if the handshake fails with later versions. There has also since been a version of the attack which also affects TLS implementations which do not properly enforce padding byte requirements as well.

The list of vulnerabilities that the TLS protocol suffers from actually goes on even further (truncation attacks, RC4 attacks, the heartbleed bug, the sweet32 attack, etc) which would make this article even more lengthy than it already is. So instead, let us away the finalization of TLS v1.3 to see which of these vulnerabilities have been taken care of and which will continue to plague us.