Overview of TLS v1.

3
What’s new, what’s removed and
what’s changed?
 About Me

• Andy Brodie
– Solution Architect / Principal Design Engineer.
– On Worldpay eCommerce Payment Gateways.
– Based in Cambridge, UK.

• I am neither a cryptographer nor a

mathematician!
– This means no maths in this presentation.
 Agenda

• History & Background.

• What’s Been Removed.
• What’s New & Changed.
– Cipher Suites.
– Handshake Changes.
– Hashed-Key Derivation Function.
– Session Resumption.
• Summary.
3
The Goals and Basics of TLS

HISTORY & BACKGROUND

4
 How SSL became TLS

When Who What Comments

1994 Netscape SSL 1.0 designed. Never published as security flaws
were found internally.
1995 Netscape SSL v2.0 published. Flaws found pretty quickly, which
led to…
1996 Netscape SSL v3.0 published. SSL becomes ubiquitous.
1999 IETF TLS v1.0 published (SSL v3.1) Incremental fixes, political name
change and IETF ownership.
2006 IETF TLS v1.1 published (SSL v3.2) Incremental fixes and capabilities.
2008 IETF TLS v1.2 published (SSL v3.3) What we should all be using!
2014 IETF TLS v1.3 draft 1 (SSL v3.4)
2017 IETF TLS v1.3 draft 21 Expires March 2018.
5
 Stop to consider the
awesomeness!

A Client and Server can have a secure conversation

over an insecure medium having never met before.
 What is a secure conversation?

• Confidentiality
– Conversation needs to be encrypted.
– Stop interception of conversations.

• Integrity
– Client & Server must be able to detect message tampering.
– Prevent MITM attacks.

• Authentication
– Client needs to trust they’re talking to the intended server.
– Stop impersonation attacks.
 TLS achieves this using various
techniques…

• Confidentiality
– Symmetric key encryption for application data.
– Typically Advanced Encryption Standard (AES).

• Integrity
– Authenticated Encryption with Additional Data (AEAD).
– Usually AES-GCM (Galois/Counter Mode).

• Authentication
– X509 certificates signed by a mutually trusted third party.
– Typically server authenticated only.
 Flow of messages in a TLS
conversation

Open Socket

Handshake

Application Data

Alert

Close Socket

9
 Flow of messages in a TLS
conversation

• Handshake
– Agree a cipher suite. Open Socket
– Agree a master secret.
– Authentication using certificate(s).
Handshake
• Application Data
– Symmetric key encryption. Application Data
– AEAD cipher modes.
– Typically HTTP.
Alert
• Alerts
– Graceful closure, or Close Socket
– Problem detected.

10
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html

TLS V1.3
 Key Goals of TLS v1.3

• Key Goals of TLS v1.3:

– Clean up - Remove unsafe or unused features.
– Security - Improve security w/modern techniques.
– Privacy - Encrypt more of the protocol.
– Performance – 1-RTT and 0-RTT handshakes.
– Continuity – Backwards compatibility.

12
WHAT’S REMOVED IN TLS V1.3?

13
 What’s removed in TLS v1.3

• Key Exchange
– RSA

• Encryption algorithms:
– RC4, 3DES, Camellia.

• Cryptographic Hash algorithms:

– MD5, SHA-1.

• Cipher Modes:
– AES-CBC.

• Other features:
– TLS Compression & Session Renegotiation.
– DSA Signatures (ECDSA ≥ 224 bit).
– ChangeCipherSpec message type & “Export” strength ciphers.
– Arbitrary/Custom (EC)DHE groups and curves.
14
 This has mitigated quite a few
attacks…

RC4 3DES
• Roos’s Bias 1995 • Sweet32
• Fluhrer, Martin & Shamir 2001
• Klein 2005 AES-CBC
• Combinatorial Problem 2001
• Vaudenay 2002
• Royal Holloway 2013
• Boneh/Brumley 2003
• Bar-mitzvah 2015
• BEAST 2011
• NOMORE 2015
• Lucky13 2013
RSA PKCS#1 v1.5 • POODLE 2014
• Lucky Microseconds 2015
• Bleichenbacher 1998
• Jager 2015
• DROWN 2016 Compression
• CRIME 2012
Renegotiation
• Marsh Ray Attack 2009 MD5 & SHA1
• Renegotiation DoS 2011 • SLOTH 2016
• Triple Handshake 2014 • SHAttered 2017 15
WHAT’S NEW AND CHANGED?

16
 What’s New and Changed?

• Cipher Suite specification.

• Handshake Encryption.
• Post-Handshake Client Authentication.
• Key Schedule Generation
• Session Handling.

17
 TLS v1.2 provides 37 Cipher
Suites

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Protocol Authentication AEAD Cipher

Mode
Key Exchange PRF Hash Algorithm

• TLS 1.2 specifies 37 cipher suites.

– Add previous versions in: 319 cipher suites.
 TLS 1.3 Cipher Suites

TLS_AES_128_GCM_SHA256
AEAD Cipher
Protocol HKDF Hash
Mode
Algorithm
• TLS v1.3 supports 5 cipher suites.
– TLS_AES_128_GCM_SHA256
– TLS_AES_256_GCM_SHA384
– TLS_CHACHA20_POLY1305_SHA256
– TLS_AES_128_CCM_SHA256
– TLS_AES_128_CCM_8_SHA256
19
 What happens to key exchange
and authentication then?

• Key Exchange algorithms:

– DHE & ECDHE
• Only 5 ECDHE curve groups supported
• Only 5 DHE finite field groups supported
– Pre-Shared Key (PSK)
– PSK with (EC)DHE

• Digital Signature (Authentication) algorithms:

– RSA (PKCS#1 variants)
– ECDSA / EdDSA

20
 TLS Handshake

• The handshake has three goals:

– Agree a cipher suite.
– Agree a master secret.
– Establish trust between Client & Server.

• Optimise for the most common use cases.

– Everyone* wants a secure conversation.
– Same cipher suites used across websites repeatedly.
– Clients connect to the same sites repeatedly.

* ok, almost everyone! 21

 Three Stages of a TLS 1.3
Handshake

Key Exchange

Server Parameters

Authentication

22
 Client now makes assumptions
about server support.

• Client sends:
– Cipher Suite options.
– List of supported groups/curves.
– (EC)DHE Key Share(s).

• Server sends:
– Cipher suite selection.
– (EC)DHE Key Share

• Client and Server now share a key.

23
 Client now makes assumptions
about server support.

• Server sends:
– Encrypted Extensions
• Server Name
• Message Length
• …and optionally many more
– Certificate Request
• Supported signature algorithms.

24
 Client now makes assumptions
about server support.

• Server sends:
– Certificate.
– Proof of private key possession.
– Finished.
– Application Data

• Client responds:
– Certificate.
– Proof of private key possession.
– Finished.

25
GENERATING KEYS USING HKDF

26
 HKDF (RFC5869)
HMAC-based Key Derivation
Function
• TLS <= v1.2 defines PRF algorithm.

• TLS v1.3 replaces this with HKDF.

– HKDF encapsulates how TLS uses HMAC.
– Re-used in other protocols.
– Separate cryptographic analysis already done.

• Provides 2 functions:
– Extract - create a pseudo-random key from inputs.
– Expand - create more keys from the extract output.

• HMAC is integral to HKDF.

– HMAC requires the Cryptographic Hash algorithm specified in the
cipher suite (SHA256 or SHA384).

27
 TLS <= v1.2 Creating Key
Material from a master secret

Client MAC Key

PRF Server MAC Key

Client Write Key

Pre-master Secret Master Secret Key Material
>= 46 bytes 48 bytes ∞ Server Write Key

Client Write IV
PRF

Server Write IV
 TLS v1.3 Key Schedule
Generation

PSK Early Secret

Client Early Traffic Early Exporter

Binder Key
Secret Master Secret
Derive Secret

Derive-Secret
(EC)DHE Handshake Secret
HKDF-Expand-Label

Derive-Secret Fixed
Client Traffic Server Traffic
Derive Secret HKDF-Extract
Handshake Secret Handshake Secret

0 Master Secret

Client Application Server App Traffic Exporter Master Resumption

Traffic Secret 0 Secret 0 Secret Master Secret

Client Application Server App Traffic

Nonce N PSK Ticket N
Traffic Secret N Secret N 29
What’s the difference?

PRE-SHARED KEYS AND SESSIONS

30
 Why do we need sessions?

• Full handshakes are expensive.

– Key generation.
– Server (& Client) Authentication.

• Many HTTP clients need it.

– Download web page resources (JS, CSS, images).
– Dynamic web pages (XHR).
– May not be feasible to keep connection open.

31
 How do we establish a PSK?

• Out-of-band
– Added to TLS in 2006 via RFC4279.

• During Handshake
– Client announces it supports session resumption.
– Provides a PSK identity during handshake.

• After handshake, Server sends “New Session Ticket”

– Contains PSK identity, nonce and max age.
– The PSK is derived from master secret.
– Server can send multiple tickets.

32
 So, TLS v1.3 supports PSK-
based session resumption

vs.

33
 What about Zero Round Trip
Time (0-RTT)?

• PSK means the key is known to both sides.

– Does this mean Client can send data immediately?
– Can we have a zero round trip time handshake?

Yes, we can!
• But…
– No forward secrecy for the “early data” sent by client.
– No guarantees of non-replay.
34
So, TLS v1.3 supports PSK-
based session resumption

35
 How to set up 0-RTT

• In initial session server sends NewSessionTicket.

– Adds max_early_data extension.

• Client connects to resume:

– Sends empty early_data extension in ClientHello.
– Includes early application data in first flight.
– Carries on passing early application data until…
– … server responds with early_data.
– Client echoes end_of_early_data to acknowledge.

36
Extensions… Extensions everywhere!

BACKWARDS COMPATIBILITY

37
 Backwards Compatibility

• Backwards compatibility is important

– TLS v1.3 clients need to talk to TLS v1.2 servers.
– TLS v1.2 clients need to talk to TLS v1.3 servers.
– Structure of Hello messages is maintained.

• 21 extensions referenced in the RFC.

– 12 in other RFCs!

38
 All the extensions

Extension TLS 1.3

server_name [RFC6066] CH, EE
max_fragment_length [RFC6066] CH, EE
status_request [RFC6066] CH, CR, CT
supported_groups [RFC7919] CH, EE
signature_algorithms [RFC5246] CH, CR
use_srtp [RFC5764] CH, EE
Acronym Message
heartbeat [RFC6520] CH, EE
CH Client Hello
application_layer_protocol_negotiation [RFC7301] CH, EE
SH Server Hello
signed_certificate_timestamp [RFC6962] CH, CR, CT
EE Encrypted Extensions
client_certificate_type [RFC7250] CH, EE
CT Certificate
server_certificate_type [RFC7250] CH, CT
CR Certificate Request
padding [RFC7685] CH
NST New Session Ticket
key_share CH, SH, HRR
HRR Hello Retry Request
pre_shared_key CH, SH
psk_key_exchange_modes CH
early_data CH, EE, NST
cookie CH, HRR
supported_versions CH
certificate_authorities CH, CR
oid_filters CR
39
post_handshake_auth CH
 Backwards Compatibility
Considerations

• Protocol Version is mentioned in every message.

– Now deprecated/fixed to old version values
– Handshake claims 1.2, App Data claims 1.0.
– New extension specifies list of supported versions.

• Fixed Values to prevent downgrade attacks.

– Server “Random” has fixed last 8 bytes
• DOWNGRD[0x01] for TLS 1.2 clients.
• DOWNGRD[0x00] for <= TLS 1.1 clients.

40
 And that’s TLS v1.3!

• Removed
– Anything that was unused, unsafe or didn’t offer value.
– Mitigated lots of attacks.

• Added
– Handshake encryption.
– 1-RTT and 0-RTT PSK / Session Resumption.

• Changed
– Cipher Suites.
– PSK / Sessions.
– Post-Handshake Client Authentication.
– PRF now HKDF.

41
THANK YOU FOR LISTENING!