TLS 1.3 Performance: Faster Handshakes and Reduced RTTs

@thisNatasha
TLS Perf:
from three to zero in one
spec
Natasha Rooney, @thisNatasha

@thisNatasha
Lots of Poppies
- Public Key Crypto
- TLS History
- TLS 1.2
- Evil RTTs
- TLS Config
- TLS 1.3
- ACME / Let’s Encrypt
- Some cool links
- Sleep.

@thisNatasha
Why do i need ssl/tls?

@thisNatasha@thisNatasha
781 data breaches
in 2015
170m records stolen
Average $3.8m per breach
http://www.idtheftcenter.org/ITRC-Surveys-Studies/2015databreaches.html
@thisNatasha

@thisNatasha
Quick intro to
Public Key Cryptography

@thisNatasha
Let’s get that Pikachu!
Jessie James

Symmetric Crypto
(Caesar Cipher)

@thisNatasha
Key = 3
=
Ohw’v jhw wkdw Slndfkx!
Jessie James

@thisNatasha
Key = 3
=
Jessie James
=

Asymmetric Crypto
2 Keys
1 Secret Key
(keep it to yourself!)
1 Public Key
(share with others)

@thisNatasha
Jessie James
PUBLIC

@thisNatasha
Jessie James
1cd87b63a2a933ca2...
PUBLIC
PUBLIC

@thisNatasha
Jessie James
1cd87b63a2a933ca2...
PUBLIC
PUBLIC
PUBLIC
1cd87b63a2a933ca2...

@thisNatasha
Does this key really
belong to james?
PUBLIC

Certs
Certificate Authority (CA)
issues a Certificate
CA checks James’s identity
Digicert, Versign
(but anyone can be a CA)

Certs
Certificate Authority (CA)
issues a Certificate
X.509
Version Number
Serial Number
Algorithm ID
Issuer
Validity period
Subject name
Subject Public Key Info
Certificate Signature Algorithm
Certificate Signature
...

@thisNatasha
Jessie James
1cd87b63a2a933ca2...
Giant Meowth
Certificate
Authority
PUBLIC
PUBLIC

SSL / TLS
Also use
Public Key Cryptography
HTTPS

@thisNatasha
7. Application Data HTTP /
IMAP
6. Data Presentation,
Encryption
SSL / TLS
5. Session and connection
management
-
4. Transport of packets and
streams
TCP / UDP
3. Routing and delivery of
datagrams on the Network
IP / IPSec
2. Local Data Connection Ethernet
1. Physical data connection
(cables)
CAT5
OSI Model

SSL
(TLS is the same, just later
versions)
SSLv1 Netscape
1994: SSLv2 Netscape
Navigator 1.1
SSLv2 Security poor
1995: SSLv3

TLS
A Crypto Protocol Framework
1996: TLS Working Group
Microsoft vs Netscape
1999: TLSv1
2006: TLSv1.1 (sec fixes)
2008: TLSv1.2 configurable
and flexible

TLS Aims
Not just crypto...
Cryptographic Security
Interoperability
Extensibility
Efficiency

TLS Aims
Don’t have a TIF
Message tampering
Message interception
Message forgery

TLS Basics
Not just crypto...
1. Handshake including
authentication and key
exchange
2. Data exchange
3. Shutdown

@thisNatasha
Er, I can see why this take
some time...

6-10 messages
Handshake
Full handshake with server
authentication
- Exchange capabilities
- Agree on params
- Validate certs
- Agree master secret
- Verify handshake was not
modified
Abbreviated handshake
(resumes earlier session)

@thisNatasha
Handshake Flow
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Key Exchange
Authentication Algorithm Strength Mode
Cipher MAC or PRF
TLS/HandshakeCheatSheet Key Exchange Method: creates the pre master secret.
Premaster secret is combined with PRF to create master
secret
RSA, DHE_RSA,
ECDHE_RSA,
ECDHE_ECDSA
Authentication Method: Uses public key crypto and
certificates public key together. Once certificate is
validated the client can used public key.
RSA or ECDSA
Certs: X.509, ASN.1
DER encoding.
Server
Hello,
Certificate
- Server selects cipher & compression
method
- Server send certificate
- Client authenticates
Key Exchange Pre-master secret exchanged between
client & server, client validates certificate
Master
Secret
Client & Server can compute Master Secret.
MAC Server verifies MAC, returns to client to
verify also.
Finished Handshake complete.
Client Hello Client sends TLS Version, Ciphersuites,
Compression methods
Ciphers, Standards and Terms
Encryption
3DES, AES, ARIA,
CAMELLIA, RC4, and
SEED
[1] Steam: adds MAC [2]
Block: adds IV and
padding after encryption
[3] Encryption (AEAD):
encryption and integrity
validation, using nonce,
no padding, no IV.
Master Secret
Pre-master secret:
combines params to
help client and server
create master secret.
Master Secret: both
server and client create
this from pre-master
secret to symmetrically
encrypt
Integrity Validation
PRF: Pseudorandom
Function. Takes a
secret, a seed, and a
unique label. TLS1.2
suites use PRF based
on HMAC and SHA256
MAC: used for integrity
validation in handshake
and record.

@thisNatasha
[1] Client Hello
Cli-ant Ser-ver
Server Hello [2]
Certificate [3]
Server Key Exchange [4]
Server Hello Done [5]
[6] Client Key Exchange
[7] (Change Cipher Spec)
[8] Finished
(Change Cipher Spec) [9]
Finished [10]
TLS Handshake

@thisNatasha
2 Roundtrips
And a lotta CPU...

Abbreviated
Handshake
Session Resumption
Client and Server keep
session security params
Session ID
Sent in ServerHello
Client sends in next
ClientHello

@thisNatasha
[1] Client Hello (+ SessionID)
Cli-ant Ser-ver
(+ SessionID) Server Hello [2]
Finished [4]
[6] Finished
TLS Abbreviated Handshake

@thisNatasha
1 Roundtrip
A lot nicer

Key Exchange
Depends on negotiated algorithm
suite and algorithm
- RSA: attackers can de-encrypt
everything if has server private
key, being replaced
- DHE_RSA: has forward secrecy but
slow
- ECDHE_RSA and ECDHE_ECDSA: Fast and
forward secrecy. Can be used with
RSA or ECDSA
- Server speaks first
- Server sends params and signature
of params for authentication

Authentication
Certificate + Public Key
Coupled with Key Exchange
Public Key Crypto (RSA or ECDSA)
RSA method:
- Client creates a random value as
premaster secret
- Encrypts with public key
- Server decrypts
- Constructs Session Keys
- Finished.

Encryption
Usually AES, 3 types.
3DES, AES, ARIA, CAMELLIA, RC4,
and SEED
AES most popular
Types:
- Stream
- Block
- Authenticated
(associated AEAD)

@thisNatashaAuthenticated
Encryption
Seq Num Header
Header Nonce Ciphertext
Plaintext
Authenticate
Encrypt

@thisNatasha
TLS Record
Type Version Length
Header Data
TLS Record
TLS Header

Renegotiation
New (encrypted) handshake
with new security params
requested...
Why?
- Requesting Client Certs
- Benefit from fully encrypted
handshake
- Different encryption strength
in different parts of the
site.

@thisNatasha
Weren’t we here to talk
about performance?

@thisNatasha
“People sometimes care about
security, but they always
care about speed; no one ever
wanted their web site to be
slower.”
Ivan Ristić

BANDWIDTH
Can buy more of this
LATENCY
This still stings. Bad.

@thisNatasha
Mobile Network:
- 3G 100-500ms latency to
base station.
- 4G < 100ms
- 100 Mbits/s stationary
- Waking from idle 100ms
- Transatlantic cables: 99.7%
the speed of light.
- Transatlantic cables:
latency < 100ms, 59ms.

@thisNatasha
SYN
Cli-ant Ser-ver
SYN + ACK
ACK
Get /page
TCP

@thisNatasha
SYN (with cookie and GET)
Cli-ant Ser-ver
SYN + ACK (and data)
TCP Fast Open

@thisNatasha
Cli-ant Ser-ver
TCP and TLS
TCP Handshake
[1] Client Hello
Server Hello [2]
Certificate [3]
Server Hello Done [5]
[8] Finished
Finished [10]
Get /page

@thisNatasha
Cli-ant Ser-ver
TCP and TLS with Session Tickets
TCP Fast Open Handshake
[1] Client Hello
Server Hello [2]
Finished [4]
[6] Finished

@thisNatasha
2 Roundtrips
Before anything is even sent

@thisNatasha
RTTs are EVIL.
They make evil people do this:

@thisNatasha
Cli-ant Ser-ver
TCP and TLS with Session Tickets
TCP Handshake
[1] Client Hello
Server Hello [2]
Finished [4]
[6] Finished

@thisNatasha
Optimise TCP
- initcwnd around 10 segments
- Slow start can restart, even after 1 second
- Keep TCP Connections Open: Use Keep Alives (HTTP1.1)

Can Tune Server
Keep Alives and Connections
Ivan’s Tests:
IE11 closes 30 secs
Safari 7 after 60 secs
Chrome 35 300 secs
Firefox 30 when server
closes.

@thisNatasha
But you can’t control what
browsers users use...

@thisNatasha
New standards could help...

TLS False Start
Send application data in Handshake
30% reduction in handshake latency
Dangerous, failure
Still in useGoogle Project

@thisNatasha
SPDY HTTP2 QUIC
Speed and security

@thisNatasha
CDN
- Edge Caching
- CDNs can manage connection
- CDNs can optimise traffic

@thisNatasha
CDN benefits outweigh any
kind TLS tuning.

Throwing Money
Solutions
Then it’ll go away...
CDNs
Bigger Server
Server Cluster

@thisNatasha
Great, but what can we
do with TLS?

@thisNatasha
Cryptographic Operations do
take (some) CPU time.

Optimising the Handshake
Key Size: Longer keys
- better protection
- More CPU intensive
Key Algorithm: RSA sucks.
- RSA required strength too slow
- ECDSA faster (3072 bit RSA)
Key Exchange: RSA, DHE or ECDHE
- RSA has no forward secrecy
- DHE is slow
- ECDHE is your friend
(security and performance are influenced by
named curve)
Key Exchange

Performance Hits: size, must be
validated, revocation checked
Certiﬁcates
Only include needed certs
Make sure a complete chain can be
created
Use ECDSA certs (1kb shorter than
RSA)
Don’t use too many hostnames on
the same cert

@thisNatasha
When certs live out their
lifetime they need to be
“revoked”, how does the
browser know?

Get your revocation info out quick,
select a fast CA,
and use OSCP stapling
Revocation
Checking
CRL: Certificate Revocation Lists
OSCP: Online Cert Status Protocol
Browsers CRLs download can be 10secs
OSCP certificate lookup in 1 request
Use CAs with fast and reliable OCSP
responders
Use CAs which update their
responders quickly
OSCP Stapling (450 bytes on
handshake)

Full handshake will happen once,
rest will be abbreviated
Session
Resumption
Server admin could:
Configure session caching so
sessions remain valid for a day
Clients do the rest!

@thisNatasha
Worst is over once the
Handshake finishes.

@thisNatasha
Transport Overhead

@thisNatasha
TCP/IP overhead is 52 bytes
per packet, properly
implemented TLS is not much!

@thisNatasha
IPv6 adds 72 bytes

@thisNatasha
Symmetric Encryption Overhead
AES_128_GCM

@thisNatasha
Not all mobile devices run
hardware-accelerated AES.

@thisNatasha
Buffering Latency
Application Payload (32kb)
TLS Record (16kb) TLS Record (16kb)
TCP Packet

TCP packets may arrive out-of-order
Need to be buffered!
Buffering Latency
Extra time:
- Buffering
- TCP Recovery (extra RTT)
- Overflowing initcwnd
TLS Tuning (experiment!):
- turn TLS record size down (16kb)
- 4kb
Better to leave to the web servers:
- Discover MTU
- They vary record size over
connection lifetime

Inequality between client and server
CPU time can be used to DoS
(but more are moving to ECDHE_RSA or
ECDHE_ECDSA)
CPU time
inequality
RSA can be used to DoS
(still uses RSA for auth)
With ECDHE_ECDSA clients will then
do 1.5 times more work

@thisNatasha
Still sounds like TLS takes a
lot of CPU energy...

In the Past
- CPUs were slow
- TLS (SSL) was heavy
- Hardware Accelerators and
Certs were expensive
Now
- Clients and Servers have fast
processors, plenty of RAM
- Hardware accelerators not needed
- Certificates are cheap
- Latency is most of the issue.

@thisNatasha
So, CPU overhead is not your
issue. RTTs and network
latencies are.

@thisNatasha
IS TLS Fast Yet?
istlsfastyet.com

@thisNatasha
So what can we do about these
RTTs?

@thisNatasha
[1] Client Hello
Cli-ant Ser-ver
Server Hello [2]
Encrypted Extensions [3]
Certificate [4]
Certificate Verify [5]
Finished [6]
[8] Finished
Finished [10]
TLS 1.3 Handshake

@thisNatasha
[1] Client Hello (KeyShare Extension)
Cli-ant Ser-ver
(KeyShare Extension) Server Hello [2]
Certificate [4]
Finished [6]
[8] Finished
Finished [10]
TLS 1.3 Handshake

@thisNatasha
[1] Client Hello (KeyShare Extension)
Cli-ant Ser-ver
(KeyShare Extension) Server Hello [2]
Certificate [4]
Finished [6]
[8] Finished
TLS 1.3 Handshake

or/ Session Resumption
TLS 1.3 Abbreviated
handshake
Identifiers and Tickets are
obsolete!
Replaces with PSK
(pre-shared key mode)
PSK created on previous connection
after the handshake
PSK then presented on next visit!

@thisNatasha
[1] Client Hello (KeyShare & pre shared key)
Cli-ant Ser-ver
(pre shared key) Server Hello [2]
Finished [4]
[5] Finished
TLS 1.3 Abbreviated Handshake (PSK)

@thisNatasha
1 RTT
Yay. Can we do better?

@thisNatasha
[1] Client Hello (KeyShare & early data)
[2] Finished
[3] ApplicationData
[4] end_of_early_data (alert)
Cli-ant Ser-ver
(KeyShare and early data) Server Hello [5]
Server Configuration [7]
Certificate [8]
Finished [10]
[11] Finished
TLS 1.3 0-RTT Handshake

@thisNatasha
Previous
Connection:
- Server sends
ServerConfiguration
after handshake
- Includes:
- Identifier
- Semi-static (EC)DH
parameters
- Expiration
- etc.

@thisNatasha
[1] Client Hello (KeyShare & early data)
[2] Finished
[3] ApplicationData (as above)
[4] end_of_early_data (alert)
Cli-ant Ser-ver
(KeyShare and early data) Server Hello [5]
Server Configuration [7]
Certificate [8]
Finished [10]
[11] Finished
TLS 1.3 0-RTT Handshake

@thisNatasha
O RTT
Or same round-trip time as for an unencrypted HTTP request

Some Caveats
0-RTT Security
No server random means replay
attacks still possible
1 RTT needed to get ephemeral
secret, so this has no Forward
Secrecy
MITM could tamper with 0-RTT data
if key is compromised

@thisNatasha
ACME / Let’s Encrypt

@thisNatasha
...webmasters often need 1-3
hours to obtain and install a
certificate for a domain

Old Certiﬁcate way
Issuance and Identity
Verification
- Generate a Certificate Signing
Request (CSR).
- ⌘C⌘V CSR into a CA webpage
- Prove domain ownership by:
- Put a CA-provided challenge on
the web server.
- Put a CA-provided challenge at
a DNS location (target domain)
- Receive CA challenge via
e-mail corresponding to the
domain and respond
- Download the certificate and
install

@thisNatasha
This is accomplished by
running a certificate
management agent on the web
server.

ACME Process
https://example.com/
Domain Validation
Agent proves to CA that the web
server controls the domain
Certifcate Issuance and Revocation
Agent requests, renews and revoke
certificates

Domain Validation
Used to be done by email...
Agent creates new key pair
Proves to CA it has access to server
CA asks domain to complete “challenges”:
- Agent creates a file on server
- CA provides a nonce
- Agent signs nonce with private key
- Agent tells CA it’s ready to complete
validation

@thisNatasha
Certificate Issuance and Revocation
- Thank-you public key crypto!
Issue Certificate
- Agent asks CA to issue a cert with a
public key
- Agent also authorises by signing with
authorised key
- CA verifies both signatures
- CA issues cert with public key from CSR
CSR: PKCS#10 Certificate Signing Request
Revoke Certificate
- Agent signs revocation request with key
pair
- CA verifies authorisation
- CA publishes to CRL, OCSP
- Browsers learn they shouldn’t accept
cert
CRL, OCSP

@thisNatasha
Lots of Poppies
- Public Key Crypto
- TLS History
- TLS 1.2
- Evil RTTs
- TLS Config
- TLS 1.3
- ACME / Let’s Encrypt
- @supersole
- Sleep.

@thisNatasha
Thank-you
People: Ivan Ristic, Eric Rescola, Patrick McManus,
Mark Nottingham, Tim Taubert, Ilya Grigorik, Yan Zhu.

@thisNatasha
Extra Credit: Multiple sites on one cert.
Ivan Ristic Says:
There’s a trick you can use if you want to keep handshake size down to a minimum but still have to host
multiple sites on the same IP address: (1) get a separate certificate for each hostname you wish to run and
configure your web server to serve these certificates to the clients that support SNI; (2) get one fallback
certificate that contains all the hostnames you have on the same IP address and configure your web server to
serve it to the clients that do not support SNI. If you do this, your SNI clients (the majority) will get
small certificates for the sites they wish to access, and everyone else (a small number of legacy clients)
will get the single long certificate.

@thisNatasha
Security of RTT Handshakes
At first glance, 0-RTT mode seems similar to session resumption or PSK, and you might wonder why one wouldn’t merge these mechanisms. The
differences however are subtle but important, and the security properties of 0-RTT handshakes are weaker than those for other kinds of TLS
data:
1. To protect against replay attacks the server must incorporate a server random into the master secret. That is unfortunately not possible
before the first round-trip and so the poor server can’t easily tell whether it’s a valid request or an attacker replaying a recorded conversation.
Replay protection will be in place again after the ServerHello message is sent.
2. The semi-static DH share given in the server configuration, used to derive the static secret and encrypt first flight data, defies forward
secrecy. We need at least one round-trip to establish the ephemeral secret. As configurations are shared between clients, and recovering the
server’s DH share becomes more attractive, expiration dates should be limited sensibly. The maximum allowed validity is 7 days.
3. If the server’s DH share is compromised a MITM can tamper with the 0-RTT data sent by the client, without being detected. This does not
extend to the full session as the client can retrospectively authenticate the server via the remaining handshake messages.
From
https://timtaubert.de/blog/2015/11/more-privacy-less-latency
-improved-handshakes-in-tls-13/

@thisNatasha
Content
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Key Exchange
Authentication Algorithm Strength Mode
Cipher MAC or PRF
Encryption Algorithm
Encryption Key Size (Strength)
Encryption Cipher Mode
3DES, AES, ARIA,
CAMELLIA, RC4, and
SEED.
Encryption: stream Plaintext + MAC
Encryption: block (encryption uses CBC
block mode)
Plaintext + MAC +
padding (encrypt) IV
(leave plain)
Encryption: authenticated (AEAD) Plaintext, seq number,
record header
(encrypt) Nonce
(leave plain)
CipherCheatSheet application protocol and the three
Handshake sub-protocols: the
Handshake Protocol, the Change
Cipher Spec Protocol, and the Alert
Protocol
Record Protocol

Other Things
Interoperability
Run an up-to-date TLS stack
Hardware Acceleration (modern CPUs
should not need this)
TLS configuration won’t make a
difference in DoS attacked

TLS 1.3 Performance: Faster Handshakes and Reduced RTTs

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to TLS 1.3 Performance: Faster Handshakes and Reduced RTTs

Similar to TLS 1.3 Performance: Faster Handshakes and Reduced RTTs (20)

More from Natasha Rooney

More from Natasha Rooney (11)

Recently uploaded

Recently uploaded (20)

TLS 1.3 Performance: Faster Handshakes and Reduced RTTs