Collaboration

Products Collection

TLS1.3 Introduce

2016年10月12日

[目录]

To understand why TLS 1.3 is awesome, we need to take a step back and look at how TLS 1.2 works.

Difference TLS1.3 with TLS1.2

How to work for TLS1.2

TLS1.2

  1. The client starts by sending a message called the ClientHello that essentially says “hey, I want to speak TLS 1.2, with one of these cipher suites”.

  2. The server receives that and answers with a ServerHello that says “sure, let’s speak TLS 1.2, and I pick this cipher suite”.

  3. The server sends the website certificate (signed by the CA) and a signature on portions of ClientHello and ServerHello, including the key share, so that the client knows that those are authentic.

  4. The client receives all that, and then generates its own key share, mixes it with the server key share, and thus generates the encryption keys for the session.

  5. The client sends the server its key share, enables encryption and sends a Finished message the server does the same: it mixes the key shares to get the key and sends its own Finished message Notice that this takes two round-trips between the client and the server before the HTTP request can be transferred

How to work of TLS1.3

Most importantly, establishing a TLS 1.3 connection takes one less round-trip. please check below

TLS1.3

  1. Client starts by sending not only the ClientHello and the list of supported ciphers, but it also makes a guess as to which key agreement algorithm the server will choose, and sends a key share for that.

  2. The server sends the ServerHello, its key share, the certificate, and already the Finished message.

  3. The client receives all that, generates the keys using the key share, checks the certificate andFinished, and it’s immediately ready to send the HTTP request, after only one round-trip

Resumption

One existing way to speed up TLS connections is called resumption. It’s what happens when the client has connected to that server before, and uses what they remember from the last time to cut short the handshake.

Work flow of TLS1.2 resumptinon1.2

The client would connect, it would send the Session ID or Ticket in the ClientHello, and the server would go like “hey, I know you, we have agreed on a key already”, skip the whole key shares dance, and jump straight to Finished, saving a round-trip.

Work flow of TLS1.3 1.3-get

2.3-post

The client connects, it sends the Session Ticket in the ClientHello and then immediately, without waiting for any round trip, sends the HTTP request encrypted with the PSK. The server figures out the PSK from the Session Ticket and uses that to decrypt the 0-RTT data.

TLS1.3 Improve

TLS 1.3 is not only good for cutting a round-trip. It’s also better, more robust crypto all around.

Most importantly, many things were removed. 1.3 marked a shift in the design approach: it used to be the case that the TLS committee would accept any proposal that made sense, and implementations like OpenSSL would add support for it. Think for example Heartbeats, the rarely used feature that cause Heartbleed.

In 1.3, everything was scrutinized for being really necessary and secure, and scrapped otherwise. A lot of things are gone:

  • the old static RSA handshake without Diffie Hellman, which doesn’t offer Forward Secrecy
  • the CBC MAC-then-Encrypt modes, which were responsible for Vaudenay, Lucky13, POODLE, LuckyMinus20… replaced by AEADs
  • weak primitives like RC4, SHA1, MD5
  • compression
  • renegotiation
  • custom FFDHE groups
  • RSA PKCS#1v1.5
  • explicit nonces

We’ll go over these in more detail in future blog posts.

Some of these were not necessarily broken by design, but they were dangerous, hard to implement correctly and easy to get wrong. The new excellent trend of TLS 1.3 and cryptography in general is to make mistakes less likely at the design stage, since humans are not perfect.

remove

simplified

simplified