title: Technical Concepts

permalink: /technical-concepts/

description: "More relevant technical concepts relating to HTTPS."

In regular TLS connections, a temporary secret key is generated by the client, encrypted using the public key of the server, and then sent over the network to the server. This means that anyone possessing a copy of the private key of the server can learn the temporary secret and then decrypt all of the traffic sent in that connection. To make matters worse, if an attacker is able to gain access to the private key, they can decrypt all past messages no matter how long ago they were as long as they still have a copy of the original encrypted data.

Forward secrecy is a mechanism which allows the client and server to agree on a temporary secret key without ever transmitting it over the network. This means that in order to decrypt traffic on the network you need both a temporary secret stored on the server *and* a temporary secret stored on the client. Possessing just one of those secrets without the other is not enough to decrypt past traffic.

In TLS, forward secrecy is provided by the [Ephemeral Diffie-Hellman (DHE)](https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange) and [Ephemeral Elliptic Curve Diffie–Hellman (ECDHE)](https://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman) key exchanges. It is ideal to have the strength of your key exchange be equivalent to that of your certificate, which means that for a 2048 bit RSA key, you want 2048 bit DHE params or roughly 256 bits for ECDHE. ECDHE is preferable to DHE because it is much faster.

There are a number of ciphers available to a TLS connection, and one of those is the [RC4](https://en.wikipedia.org/wiki/RC4) (Also known as ARC4 or ARCFOUR). RC4 was a popular cipher due to being a fast cipher which was not vulnerable to the [BEAST](https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls) attack. However in 2013 it was announced that [RC4 had a serious flaw](http://www.isg.rhul.ac.uk/tls/) that would make it possible for a determined attacker to decrypt data encrypted with RC4 in TLS.

Due to the serious flaw in RC4 and the fact that the BEAST attack has been mitigated by all modern browsers, all HTTPS sites should be configured to use ciphers other than RC4.

HTTPS today uses **Transport Layer Security (TLS)**. TLS is a network protocol that establishes an encrypted connection to an authenticated peer over an untrusted network.

Earlier, less secure versions of this protocol went by the name **Secure Sockets Layer (SSL)**.

SSL and TLS do the same thing, and because of its early ubiquity, "SSL" is frequently used today to generically refer to TLS/HTTPS. However, all versions of SSL as a protocol are now considered insecure for modern use.

A key component of the TLS security model is X.509 certificates, which use cascading signatures. A root certificate authority's certificate (which is included with your OS) is used to sign an intermediary certificate, which is used to sign your website's certificate.

A part of this signature process is computing the hash of the data included in the certificate. Right now the [web is in the process of migrating the recommended hashing algorithm from SHA-1 to SHA-256](http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html), as a result of increasingly advanced cryptanalysis of SHA-1.

Any new certificates you acquire will generate the "yellow lock" icon in Chrome if they, or any of the intermediary certificates in the chain, use SHA-1. Therefore when generating a new certificate it's important to check with your CA to make sure both your certificate, and their intermediates, use SHA-256.

Opening a TLS connection is a fairly expensive and slow process which includes several round trips of data and some fairly slow cryptography. It's not unusual for the handshake to take 300ms or more to fully complete. However TLS includes two different mechanisms which allow a client to reuse a previous handshake for a period of time to reduce the time it takes to establish a secure connection.

The first of these methods is called Session ID. In this method the server generates a unique identifier for the connection and records all of the information it needs to reuse a handshake under that ID. It then communicates the unique identifier to the client. When the client receives the unique identifier it also records the information it needs to reuse the connection along with the unique identifier. On subsequent connections it will tell the server that it has a previous session by including the unique identifier when it first starts to open the connection. When the server sees that the client is attempting to connect it will notice that it included a session ID, and if it has the information still recorded it will tell the client to just reuse that session instead of finishing the longer handshake.

Session IDs rely on storing per client state on the server and if you have more than one server terminating TLS it requires a strategy to ensure that when the client connects they will connect to a server that knows about their session ID. The two primary ways of doing this are by using a shared storage method and by ensuring that the same client is likely to get routed to the same server each time.

The second method is called Session Tickets, and like session IDs it works by recording all of the information needed for the server to reuse the existing handshake. However instead of storing this on the server and generating a unique identifier the server encrypts this data and then gives it to the client in the form of a session ticket. When the client attempts to establish a new connection it will include this session ticket and, if the server can decrypt it, the server and client can reuse the previous handshake through the information included in that ticket.

Using session tickets requires similar strategies to Session IDs, except instead of needing to share session data between all servers all servers must be configured with the same secret key which is used to encrypt the session tickets or a client must be routed to the same server as their last connection.

The use of these methods to resume a previous session can greatly speed up the creation of a new TLS connection, allowing the connection to skip doing the most expensive parts of the handshake. However if they are not handled carefully they can [remove the benefit of forward secrecy](https://www.imperialviolet.org/2013/06/27/botchingpfs.html) because anyone who is able to access the session data can decrypt anything sent using any connection that relied on that session data.