Transport Layer Security (TLS/SSL)

[Warning : Unfinished post]

To secure the transit communication between its web browser and remote servers, Netscape Communications designed the Secure Sockets Layer (famously abbriviated as SSL) protocol in 1994. The SSLv1 never made it to the public, since it had several shortcomings and flaws :

• It wasn’t tamper-proof
• Use of the weak stream cipher RC4
• Vulnerable to replay attacks (no sequence numbers)

SSLv2 was the first publicly released version in 1995, with SSLv3 RFC6101 following the next year. The sole purpose of SSL is to provide authentication, confidentiality and integrity, although authentication was later added through the use of chain of trust and certificates.

Definition: A digital certificate certifies the ownership of a public key by the named subject of the certificate, and indicates certain expected usages of that key.

Here is what a network Evesdroper can learn from intercepting transit traffic :

When you use it correctly, a third-party observer can only infer the connection endpoints (IP layer), type of encryption, as well as the frequency and an approximate amount of data sent, but cannot read or modify any of the actual data. source

In 2015 all SSL versions were finally deprecated by the Internet Engineering Task Force (IETF) RFC7568 due to a long series of known attacks, both on the key exchange mechanisms and the encryption schems. I advise the interested reader to refer to this Wikipedia link, where you’ll find an explanation of previous attacks. Also IETF issued an informational RFC summarizing all the attacks. And if you’re just wondering whether your server has any TLS weaknesses, I highly recommend using this tool, sslyze, which is a fast and powerful SSL/TLS server scanning python library.

Then comes Transport Layer Security (TLS), a successor to SSL, now designed and standardized by IETF. TLS 1.0 was first defined in RFC2246 in January 1999 as an upgrade of SSL version 3.0, TLS 1.1 was defined in RFC4346 in April 2006, TLS 1.2 defined ini RFC5246 in August 2008, and now the March 2018 draft of TLS 1.3 was approved for use, which will make all secure internet connections faster and safer, due to the elimination of unnecessary handshake steps and the forced use of newer encryption methods.

For the coming information to make sense, I have to insert the general structure of the TLS protocol and its place in the network stack early in the article (don’t worry if you don’t understand some of the terms).

TLS protocol in the network stack

Before the client and server can start exchanging encrypted data using TLS, both parties must decide on whether to use it in the first place. At a more technical level, and by taking HTTP as an example, what would the server expect after a successfull TCP handshake, the start of a TLS handshake or the HTTP request itself ? The root of the problem is that applications can communicate either with or without TLS. To solve the confusion, the client must indicate to the server the setup of a TLS connection. While there are many ways to achieve this, only two are widely used :

1. Assign a different port number, for example, HTTP on 80, HTTPS on 443.
2. Opportunistic TLS : client makes a protocol-specific request to the server, for example, STARTTLS for SMTP/IMAP/POP3/FTP … while using the same port.

Given both ends agreed to use TLS, the famous TLS handshake begins. The handshake consists of a series of exchanged packets (to be more accurate, TLS records) to build a secure tunnel over the otherwise unsecure internet. If you search for images depicting the handshake diagram, you will find many, with each one giving a different graph. The reason behind this, is TLS comes bundled with a huge list of so-called cipher suites. Each one gives a sligthly different handshake/diagram. IANA defined a list of named cipher suites used by TLS.

Definition: A cipher suite is a set of algorithms that are used together in a TLS session. The set usually includes: a key agreement algorithm for exchanging a symmetric session key to use for encryption, a bulk encryption algorithm, and a message authentication code for integrity purposes. Asymmetric algorithms can also be found in the set mainly for authentication purposes.

The figure given below gives a diagram of TLS handshake when using RSA as the key exchange protocol (for example, TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suite).

TLS handshake protocol source

As most networking protocols, TLS defines a frame/format as the most basic unit to exchange data. record is the name given to this frame. It is actually a whole sub-protocol in itself, and it is stacked directly on top of TCP. The job of the Record protocol is first fragment the higher-layer protocol data (refer to Figure xx) into blocks of 2¹⁴ bytes or less; then optionally compress the data (a step rarely done), adds a Message Authentication Code and finally encrypts the data according to the cipher spec (once negotiated), then add an SSL Record hearder.

The general format of all TLS records is shown below.

TLS record

Note: TLS supports compression of its protocol messages, MAC and padding. To my knowledge, there is no out-of-the-box SSL/TLS implementation that supports it.

Here is a diagram that depicts the process of building an SSL Record by the Record protocol.

Building TLS Record source

The higher layer is stacked on top of the Record Protocol. Each of these protocols has a very specific purpose, and are used at different stages of the communication. the Content type field of the Record header specifies the higher layer protocol type of the record. The table below gives all possible content types wrapped inside a record.

The Handshake protrocol (Hex 0x16) is the most used record type found within a TCP setup, in addition to Alert and ChangeCipherSpec protocols. The format of the Handshake protocol within a record frame is shown below.

Handshake protocol format Source

Message type is the field that identifies the handshake message type, and these are:

The handshake is usually initiated by sending ClientHello message. It is sent with a list of client-supported cipher suites for the server to pick the best one, a list of compression methods, and a list of extensions. Here is an example:

ClientVersion 3,1
ClientRandom[32]
SessionID: None (new session)
Suggested Cipher Suites:
   TLS_RSA_WITH_3DES_EDE_CBC_SHA
   TLS_RSA_WITH_DES_CBC_SHA
Suggested Compression Algorithm: NONE

The server responds with a set of handshake messages (often bundled within the same TCP packet), comprising a ServerHello where it puts the chiper, compression method and extensions chosen; a Certificate message, an optional ServerKeyExchange and ServerHelloDone. When the ServerKeyExchange doesn’t appear in the response from the server, it is usually an indication of a setup of a weak key agreement protocol.

RSA, Diffie-Hellman and Forward Secrecy

There are basically two methods to key agreement protocols: either through the use of Diffie-Hellman protocol, or one of other public-key algorithms, for example, RSA, ECDSA. As the name implies, such a protocol aims to securely exchange a session key between two ends.

When DH or one of its variants is not in use, for example, using RSA, the client calculates the master key independently (actually a pre-master key form which the master key is derived) from the server, then encrypts it with the server’s public key (which only the owner of the private key can decrypt) and sends it in the ClientKeyExchange handshake message. There are two obvious flwas when using this method:

1. If an attacker ever gains access to the server’s private key, he can learn the session key and decrypt the otherwise encrypted traffic.
2. Worse, the attacker is not only limited to decrypting traffic of current session, but all recorded previous traffic can be decrypted now.

On the other hand, The session key agreed upon using Diffie-Hellman protocol never leaves the client or server machines, so can not be intercepted by an evesdropper. furthermore, using specific DH variants (ephemeral DH and ephemeral Elliptic Curve DH), one can take advantage of their PFS feature; meaning, even if the private key is compromised at one point in time, none of the previous recorded traffic can be decyrpted.

Often you’ll find an additional authentication mechanism used with DH (e.g. RSA, PSK or ECDSA) because DH itslef is an unauthenticated protocol: anyone can claim to be the destination server and start the key exchange with the client.

ApplicationData Protocol format

The mission of this protocol is to properly encapsulate the data coming form the Application layer of the network stack.

Application Protocol format source

Attacking SSL/TLS Heartbeat Extension

CVE-2014-0160 or most commonly known as Heartbleed, was the first huge vulnerability in 2014 that wrecked havoc all over the internet. Over 500.000 or so HTTPS certificates may have been compromised by the catastrophic Heartbleed bug. The bug resides within the ubiquitous openssl library, and it occurs due to bounds checking not being performed on a heap value which is user supplied and returned to the user as part of DTLS/TLS heartbeat SSL extension RFC6520. All versions of OpenSSL 1.0.1 to 1.0.1f are known affected. A successfull exploit will return a dump up to 65535 bytes of server memory per request. If you get lucky enough, you may end up retrieving the server’s private key.

In this section, we will write a python code to exploit this vulnerability; actually it is a re-write of HackerFantastic’s C code exploit.