What are TLS extensions?

The widespread Transport Layer Security protocol (TLS), a successor of the better-known SSL protocol, includes a very thoughtful mechanism to add an additional functionality to the protocol. Using the so-called extensions we can extend the TLS capabilities as we desire without actually modifying the protocol itself.

The extensions were firstly introduced in the RFC 3456 and later fully incorporated into the TLS itself. The client states which extensions it supports during the handshake (in the ClientHello message) and the server chooses which extensions to use at its sole discretion.

Many extensions are commonly used in the wild. In this article, I'm picking just a few out of many to introduce the concept and describe one of the most popular extensions today.

Server Name Indication [server_name]

This extension enables browsers to send the destination hostname as a part of a TLS handshake. Because of the shortage of IPv4 addresses, it's very common that multiple hosts are on the same IP address. In plain HTTP this is solved via the Host request header, which includes the same thing - the hostname.

Let's assume you want to make a HTTPS connection to www.susanka.eu. This website sits at IP 88.90.30.48 as does www.tsusanka.cz. The handshake starts and the server needs to provide a certificate, which is bound to the domain name. Since both tsusanka.cz and susanka.eu sit at the same machine with the same IP, how can it know which certificate to present?

And that's exactly where the Server Name Indication comes in handy. The client simply includes the hostname in the TLS handshake and the server knows right away which certificate to present.

Elliptic Curves capabilities [elliptic_curves]

This extension helps the client to specify what elliptic curves it supports. For example, the Elliptic Curves Key Exchange (ECDH) operates on some particular elliptic curve, where the mathematical voodoo occurs.

Let's spin up a TLS connection inside Firefox by simply visiting a HTTPS website. When inspected in Wireshark you can see that the ClientHello includes this extension and specifies which ECs it supports.

We can read from the image that our browser supports four elliptic curves. Let's dig a little bit more into the first one.

The ecdh_x25519 stands for the widely used Curve25519. On wikipedia and in the official RFC 7748 we can find that the curve is specified by the formula:

$ y_2 = x_3 + 486662 x_2 + x $

That it is a Montgomery curve, over the quadratic extension of the prime field defined by the prime number $2^{255} − 19$ and it uses the base point $x=9$

I always had a little bit of trouble understanding why it is this arbitrary curve and not another one. Why this prime number? Why multiply by 486662 and not another number that fit as well? Well, the answer to that is somewhat unsatisfactory. The choice of those constants and the form of the curve is simply to allow some performance tricks to achieve faster computations. Researchers simply found out that we can do some very specific tricks on this curve which makes it a nice fast curve to be used for cryptography. That's it, I'm afraid. Feel free to dive into the official paper.

Session tickets [session_ticket]

The TLS handshake is a costly operation. It requires two round-trips and on top of that, the cryptographic operations are CPU-exhaustive. TLS itself incorporates a mechanism called session resumption to abbreviate the handshake. The server assigns the session a unique ID and both the client and the server store the session details under such ID. During the next handshake, both sides simply state the ID and the connection is resumed using the stored data.

This mechanism, however, contains one big caveat – the server needs to store the session details for every client. That can add up to a lot of data! For that reason session tickets extension delegates the data-storing exclusively to the client.

The server sends all the session data (encrypted) to the client and the client stores it and sends it back to the server on resumption. No server-side storage is then needed whatsoever.

This was just a brief introduction into the extensions mechanism. I wanted to demonstrate that using the extensions you can extend or modify the TLS protocol as you desire.