Christopher Baines

Government Digital Service

HTTP and Security

HyperText Transfer Protocol: High level protocol that web browsers and web applications use to communicate.
Security: In this context, this means secrecy, authenticity and integrity.

All three of these security criteria are important, taking GOV.UK as an example:

A lack of secrecy could mean that others on the network could see what pages you are viewing.
A lack of authenticity could mean that you are not actually looking at GOV.UK, but something pretending to be.
A lack of integrity could mean that you are talking to GOV.UK, but the information you are seeing has been altered, and is not what was originally sent by the server.

How does HTTPS fit together
- Where does it fit in
- The handshake
Security
- Integrity
- Secrecy
- Authenticity
The future, TLS 1.3

Protocols involved

HTTP (HyperText Transport Protocol)

TLS (Transport Layer Security)

TCP (Transmission Control Protocol)

IP (the Internet Protocol)

IEEE 802.3 (Ethernet) / IEEE 802.11 (Wi-Fi) / ...

Transport Layer Security (TLS)

Evolution of the SSL protocol
Several versions exist:
- SSL 1.0 (never released)
- SSL 2.0 (released in 1995)
- SSL 3.0 (released in 1996)
- TLS 1.0 (standardised in 1999)
- TLS 1.1 (standardised in 2006)
- TLS 1.2 (standardised in 2008)
- TLS 1.3 (draft)

The Handshake

TLS 1.2 Full Handshake

Client                                               Server

ClientHello                  -------->
                                                ServerHello
                                               Certificate*
                                         ServerKeyExchange*
                                        CertificateRequest*
                             <--------        ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                     -------->
                                         [ChangeCipherSpec]
                             <--------               Finished
Application Data             <------->       Application Data

* Indicates optional or situation-dependent messages that
  are not always sent.

RFC 5246

Cipher Suites

This is the initial state of the TLS connection:

TLS_NULL_WITH_NULL_NULL

This is an example of a modern cipher suite:

TLS_ECDHE_WITH_AES_128_GCM_SHA256

ECDHE: Eliptic Curve Diffie Hellman Ephemeral
AES 128 GCM: Advanced Encryption Standard with 128 bit blocks using Galois/Counter Mode
SHA256: Secure Hash Algorithm with a digest of 256 bits

TLS Session Resumption

Important to consider when looking at speed and security
Two modes:
- Session IDs (data stored client-side and server-side)
- Session Tickets (data stored client-side)

With session ids, the cryptographic data about the connection is stored on both the client and the server.

The client sends the session id during the handshake, and if the server supports re-establishing sessions, and remembers the details of the session identified by the session id, it will reply with a server hello message with the same session id value.

If the server does not remember the details of the session, the full handshake continues as normal.

Session resumption with session ids can be tricky to setup, if you are using multiple machines to handle TLS connections, to get the most benefit, the session data needs to be available from all of the machines, otherwise clients connecting might not connect again to the same machine that they previously talked to, and to a different one that does not hold the data corresponding with the session id.

With session tickets, the server does not need to store the data for the connection, as this is what the ticket contains. When the server generates the ticket, it encrypts it with a key that only it knows.

This poses similar problems to session ticket ids. While the server does not need to store all the session information, but just the key, that key needs to be shared between any server that handles those session tickets.

The session tickets also pose a problem for forward secrecy, as if you were able to acquire the session ticket key, you could decrypt the session tickets for past connections, and decrypt the traffic.

Because of this, it's important to rotate the session ticket key.

Sources:

TLS 1.2 with session resumption

Client                                                Server

ClientHello                   -------->
                                                 ServerHello
                                          [ChangeCipherSpec]
                              <--------             Finished
[ChangeCipherSpec]
Finished                      -------->
Application Data              <------->     Application Data

RFC 5246

Integrity

Methods used to provide integrity

Digital Signatures: Use public key cryptography to produce signatures that can be authenticated, and that are difficult to forge.
Authenticated Encryption with Associated Data (AEAD): These provide secrecy as expected from a cipher, but in a way that also provides integrity and authenticity.
Message Authentication Codes: One way hash function computed from a message and secret data. It must be difficult to forge.

Secrecy

Security of application data in TLS

For secrecy, the data sent over TLS is encrypted with a semetric cipher, e.g. AES.
This is only secure if somehow the client and the server can agree on a key to use, without anyone else finding out.

Using RSA for the key exchange

RSA: Public key cryptosystem, first published by Ron Rivest, Adi Shamir, and Leonard Adleman.

The client generates a random value to be used as the key.
The client then encrypts this value with the server public key, and sends it to the server.
The server then decrypts the value, and uses it in the connection.

Forward Secrecy

A protocol is said to have perfect forward secrecy if compromise of long-term keys does not compromise past session keys.

As the above definition says, a protocol is said to have forward secrecy if a comprimise of the long-term keys does not comprimise past session keys
In the context of using RSA for the key exchange, the long-term session key is the servers public-private keypair, and the session keys are the secret values that the clients encrypts to be used as the key for the semetric cipher.
With using RSA for the key exchange, anyone with access to the private part of the servers keypair can decrypt the encrypted session keys sent from the server to the client.
This would work, even if you acquire the private key long after the exchange took place. For example, if you record all the traffic to and from a server, you could then later acquire the private key, decrypt all the session keys, and then using them, decrypt all the traffic.
Now, this isn't really bad, and it doesn't mean the system is broken, but in the case of TLS, it's not a comprimise that you have to make. Providing the server and client support the right ciphersuites, you can get forward secrecy.

Sources:

https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection

Diffie Hellman

Public key distribution system
It has come to be known by those who first published it, Whitfield Diffie and Martin Hellman.

To set the scene a bit, all the public key cryptography on the internet relies one or more of just 3 mathematical problems, factoring integers into primes, which is what RSA relies on, discrete log modulo primes, and discrete log in elliptic curve groups.

We are now going to look at these last two, discrete log modulo primes, and discrete log in eliptic curve groups.

Diffie Hellman is an example of a public key distribution system, which is different from a public key cryptosystem.

It is named after those who published the paper describing this new approach, Whitfield Diffie and Martin Hellman.

When using Diffie-Hellman, two parties send messages back and forth until they have computed a shared key. Any third parties monitoring this communication must find it infeasible to also compute the key.

This is a perfect solution to the problems with using RSA for the TLS key exchange with respect to forward secrecy, as with diffie hellman, there is no long term key.

Sources:

Modular Arithmetic

\[(4 + 4) \bmod 5 = 3\]

                *
0 1 2 3 4 5 6 7 8 9 10
0 1 2 3 4 0 1 2 3 0 1

\[(2 * 3) \bmod 5 = 1\]

            *
0 1 2 3 4 5 6 7 8 9 10
0 1 2 3 4 0 1 0 1 2 3

Alice and bob agree to use a modulus \(p = 23\) and base \(g = 5\).

Alice chooses a secret integer \(a = 6\)
Alice then computes the public integer \(A = g^a \bmod p\)
\(\implies\) \(5^6 \bmod 23 = 8\)

Bob chooses a secret integer \(b = 15\)
Bob then computes the public integer \(B = g^b \bmod p\)
\(\implies\) \(5^{15} \bmod 23 = 19\)

Alice and Bob share their public integers \(A\) and \(B\)

Alice then computes the shared secret \(s = B^a \bmod p = 19^6 \bmod 23 = 2\)
Bob then computes the shared secret \(s = A^b \bmod p = 8^{15} \bmod 23 = 2\)

When Alice computes the shared secret \(s\)

\(s = B^a \bmod p\)
\(B = g^b \bmod p\)

substituting \(s = (g^b \bmod p)^a \bmod p\)

This can be simplified to:

\(s = g^{ab} \bmod p\)

Cracking Diffie Hellman

\(b = log_g B \bmod p\)

\(s = A^b \bmod p\)

Guess at b (Bobs secret, which is 15)	Calculation
\(guess\)	\(A^{guess} \bmod p = ...\)
\(2\)	\(8^2 \bmod 23 = 18\)
\(3\)	\(8^3 \bmod 23 = 6\)
\(4\)	\(8^4 \bmod 23 = 2\)
\(5\)	\(8^5 \bmod 23 = 16\)
...

Back to ciphersuites... and Eliptic Curve Diffie Hellman

You probably won't use Diffie Hellman in its original form.
The approach generalises to finite cyclic groups.
A preferred form is using eliptic curve groups, rather than a group of multiplicative group of integers modulo n.

You probably won't be using diffie hellman in the way described previously when your browsing the web over TLS·

A preferred approach is to use diffie hellman, but with an eliptic curve group. For equivalent security, DHE requires significantly more compute resource than using RSA for the key exchange, whereas using ECDHE has only a small overhead.

The maths is different, but the approach is the same. Instead of the finite field being a prime number of integers, its a set of points on a algebraic curve known as an eliptic curve.

The shared parameters are those of the curve. The secrets are some integers. The public values are computed by performing the scalar multiplication of a particular point on the curve, known as the generator, by the secrets.

These public points are then exchanged, and then each party does another scalar multiplication with their secret integer. The resulting point is the shared secret.

This isn't much more complicated that diffie hellman as previously discussed, the main difficulty is defining how to do scalar multiplication over points on an eliptic curve.

Hopefully, whenever you have doubts about how TLS actually even works, especially how you can get forward secrecy, you might remember enough of how Diffie Hellman works that you can convince yourself once more that it actually might work.

https://blog.twitter.com/2013/forward-secrecy-at-twitter-0
https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/

Authenticity

TLS 1.2 Full Handshake

Client                                               Server

ClientHello                  -------->
                                                ServerHello
                                               Certificate*
                                         ServerKeyExchange*
                                        CertificateRequest*
                             <--------        ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                     -------->
                                         [ChangeCipherSpec]
                             <--------               Finished
Application Data             <------->     Application Data

* Indicates optional or situation-dependent messages that
  are not always sent.

RFC 5246

For server authentication, the client uses the server's public key to encrypt the data that is used to compute the secret key. The server can generate the secret key only if it can decrypt that data with the correct private key.

As well as encrypting the data used to compute the secret key, the client will hopefully check that it trusts the certificate.

There is a number of things that can be checked here, ideally you want to check that the certificates involved haven't expired or been revoked, and that you can establish a trust chain from the certificate you are using to one that you trust.

The trusted root certificates are normally selected by the operating system, or web browser.

HTTP Strict Transport Security (HSTS)

Strict-Transport-Security: max-age=31536000

Strict-Transport-Security: max-age=31536000; includeSubDomains

Strict-Transport-Security: max-age=31536000; includeSubDomains;
preload

HTTP Strict Transport Security (abbreviated to HSTS) is an opt in security enhancement.
The Strict-Transport-Security response header tells a web browser that the site should only be communicated with over HTTPS.
Using this header can mitigate some MITM attacks, given certain conditions
- Those connecting to a website that supports HTTPS may initially connect over HTTP.
- This initial insecure connection can allow an attacker to take control, e.g by redirecting you to a fake site instead.
- HSTS can help prevent this, as it allows sites to say that connections should always be made over HTTPS, so only the very first connection to the site is vulnerable.
- In addition to this, many browsers support a "preload" list. This contains the HSTS information for many sites, but in the browser itself, meaning that the initial connections to these sites don't have to be made over HTTP, as the browser already knows that all connections should be made over HTTPS.

Sources:

The Future

TLS 1.3

TLS 1.3 Handshake

Client                                               Server

ClientHello
+ key_share               -------->
                                                ServerHello
                                                + key_share
                                      {EncryptedExtensions}
                                      {CertificateRequest*}
                                             {Certificate*}
                                       {CertificateVerify*}
                                                 {Finished}
                          <--------     [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished}                -------->
                          <--------        [NewSessionTicket]
[Application Data]        <------->      [Application Data]

Draft TLS 1.3 Spec

TLSv1.3 0-RTT Resumption

Client                                               Server

ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*)     -------->
                                                ServerHello
                                           + pre_shared_key
                                               + key_share*
                                      {EncryptedExtensions}
                                              + early_data*
                                                 {Finished}
                        <--------       [Application Data*]
(EndOfEarlyData)
{Finished}              -------->

[Application Data]      <------->        [Application Data]

Draft TLS 1.3 Spec

An overall view of HTTP and security

Mathematical Problems: Factoring, Discrete log
Cryptographic Primitives: RSA, Diffie-Hellman, DSA, AES, SHA-1, ...
Protocols: TLS, ...
Library Implementations: OpenSSL, GnuTLS, ...
Software Applications: Firefox, Chromium, Apache, NGinx, ...

Christopher Baines

Government Digital Service