Overview of TLS v1.3 Whats new, whats removed and whats changed? - - PowerPoint PPT Presentation

overview of tls v1 3
SMART_READER_LITE
LIVE PREVIEW

Overview of TLS v1.3 Whats new, whats removed and whats changed? - - PowerPoint PPT Presentation

Overview of TLS v1.3 Whats new, whats removed and whats changed? About Me Andy Brodie Worldpay Principal Design Engineer. Based in Cambridge, UK. andy.brodie@owasp.org Neither a cryptographer nor a mathematician!


slide-1
SLIDE 1

Overview of TLS v1.3

What’s new, what’s removed and what’s changed?

slide-2
SLIDE 2

About Me

  • Andy Brodie

– Worldpay Principal Design Engineer. – Based in Cambridge, UK.

– andy.brodie@owasp.org

  • Neither a cryptographer nor a mathematician!

– This means no maths in this presentation.

slide-3
SLIDE 3

Agenda

  • History & Background.
  • What’s Been Removed.
  • What’s New & Changed.

– Cipher Suites. – Handshake Changes. – Hashed-Key Derivation Function. – Session Resumption.

  • Summary.

3

slide-4
SLIDE 4

HISTORY & BACKGROUND

The Goals and Basics of TLS

4

slide-5
SLIDE 5

How SSL became TLS

5

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) 2018 IETF TLS v1.3 draft 23 Expires July 15

slide-6
SLIDE 6

Stop to consider the awesomeness!

A Client and Server can have a secure conversation

  • ver an insecure medium having never met before.
slide-7
SLIDE 7

What is a secure conversation?

  • Privacy

– Conversation must be encrypted. – Prevent eavesdropping attacks.

  • Integrity

– Client & Server must be able to detect message tampering. – Prevent Man In The Middle (MITM) attacks.

  • Authentication

– Client needs to trust they’re talking to the intended server. – Prevent impersonation attacks.

slide-8
SLIDE 8

TLS achieves this using various techniques…

  • Privacy

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

  • Integrity

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

  • Authentication

– X509 certificates signed by a mutually trusted third party. – Typically server authenticated only.

slide-9
SLIDE 9

Flow of messages in a TLS conversation

9

Handshake Alert

Open Socket Close Socket

Application Data

slide-10
SLIDE 10

Flow of messages in a TLS conversation

  • Handshake

– Agree a cipher suite. – Agree a master secret. – Authentication using certificate(s).

  • Application Data

– Symmetric key encryption. – AEAD cipher modes. – Typically HTTP.

  • Alerts

– Graceful closure, or – Problem detected.

10

Handshake Alert

Open Socket Close Socket

Application Data

slide-11
SLIDE 11

TLS V1.3

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

slide-12
SLIDE 12

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

slide-13
SLIDE 13

WHAT’S REMOVED IN TLS V1.3?

13

slide-14
SLIDE 14

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

slide-15
SLIDE 15

This has mitigated quite a few attacks…

15

RC4

  • Roos’s Bias 1995
  • Fluhrer, Martin & Shamir 2001
  • Klein 2005
  • Combinatorial Problem 2001
  • Royal Holloway 2013
  • Bar-mitzvah 2015
  • NOMORE 2015

MD5 & SHA1

  • SLOTH 2016
  • SHAttered 2017

AES-CBC

  • Vaudenay 2002
  • Boneh/Brumley 2003
  • BEAST 2011
  • Lucky13 2013
  • POODLE 2014
  • Lucky Microseconds 2015

RSA-PKCS#1 v1.5 Encryption

  • Bleichenbacher 1998
  • Jager 2015
  • DROWN 2016

Compression

  • CRIME 2012

Renegotiation

  • Marsh Ray Attack 2009
  • Renegotiation DoS 2011
  • Triple Handshake 2014

3DES

  • Sweet32
slide-16
SLIDE 16

WHAT’S NEW AND CHANGED?

16

slide-17
SLIDE 17

What’s New and Changed?

  • Cipher Suites.
  • Handshake.
  • Hashed-Key Derivation Function (HKDF).
  • Key Schedule.
  • Sessions.

17

slide-18
SLIDE 18

CIPHER SUITES

slide-19
SLIDE 19

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Protocol Key Exchange AEAD Cipher Mode PRF Hash Algorithm Authentication

TLS v1.2 provides 37 Cipher Suites

  • TLS 1.2 specifies 37 cipher suites.

– Add previous versions in: 319 cipher suites.

slide-20
SLIDE 20

TLS 1.3 Cipher Suites

  • 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

20

TLS_AES_128_GCM_SHA256 AEAD Cipher Mode HKDF Hash Algorithm Protocol

slide-21
SLIDE 21

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

21

slide-22
SLIDE 22

HANDSHAKE CHANGES

slide-23
SLIDE 23

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.

23

* ok, almost everyone!

slide-24
SLIDE 24

TLS 1.2 Handshake

slide-25
SLIDE 25

Three Stages of a TLS 1.3 Handshake

25

Key Exchange Server Parameters Authentication

slide-26
SLIDE 26

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.

26

slide-27
SLIDE 27

The rest of the handshake is encrypted.

  • Server sends:

– Encrypted Extensions

  • Server Name
  • Message Length
  • …and optionally many more

– Certificate Request

  • Supported signature algorithms.

27

slide-28
SLIDE 28

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.

28

slide-29
SLIDE 29

Efficiency Gains

29

slide-30
SLIDE 30

GENERATING KEYS USING HKDF

30

slide-31
SLIDE 31

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).

31

slide-32
SLIDE 32

How the PRF is implemented

32

Key Material HMAC(SHA-256)

label + seed

PRF(secret, label, seed) P_HASH(secret, label + seed)

slide-33
SLIDE 33

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

Pre-master Secret Master Secret Key Material Server Write Key Client Write Key Client Write IV Server Write IV Server MAC Key Client MAC Key

48 bytes >= 46 bytes

∞ PRF PRF

slide-34
SLIDE 34

TLS v1.3 Key Schedule Generation

34

Client Early Traffic Secret Binder Key Handshake Secret Client Traffic Handshake Secret Server Traffic Handshake Secret (EC)DHE Client Application Traffic Secret 0 Derive Secret PSK Early Secret Early Exporter Master Secret Master Secret Derive Secret Server App Traffic Secret 0 Exporter Master Secret Resumption Master Secret Client Application Traffic Secret N Server App Traffic Secret N Derive-Secret HKDF-Expand-Label HKDF-Extract Derive-Secret Fixed PSK Ticket N Nonce N

slide-35
SLIDE 35

PRE-SHARED KEYS AND SESSIONS

What’s the difference?

35

slide-36
SLIDE 36

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.

36

slide-37
SLIDE 37

How do we establish a PSK?

  • Out-of-band

– Added to TLS in 2006 via RFC4279.

  • During Handshake

– Client announces it supports session resumption. – Server provides a PSK identities 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.

37

slide-38
SLIDE 38

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

38

becomes…

slide-39
SLIDE 39

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?

39

Yes, we can!

  • But…

– No forward secrecy for the “early data” sent by client. – No guarantees of non-replay.

slide-40
SLIDE 40

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

40

becomes…

slide-41
SLIDE 41

BACKWARDS COMPATIBILITY

Extensions… Extensions everywhere!

41

slide-42
SLIDE 42

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.

– 12 extensions defined in the RFC. – 9 extensions defined in other RFCs.

  • E.g. server key exchange message replaced with

key_share extension.

42

slide-43
SLIDE 43

All the extensions

43

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 heartbeat [RFC6520] CH, EE application_layer_protocol_negotiation [RFC7301] CH, EE signed_certificate_timestamp [RFC6962] CH, CR, CT client_certificate_type [RFC7250] CH, EE server_certificate_type [RFC7250] CH, CT padding [RFC7685] CH key_share CH, SH, HRR 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

  • id_filters

CR post_handshake_auth CH Acronym Message CH Client Hello SH Server Hello EE Encrypted Extensions CT Certificate CR Certificate Request NST New Session Ticket HRR Hello Retry Request

slide-44
SLIDE 44

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.

44

slide-45
SLIDE 45

And that’s TLS v1.3!

  • Removed

– Anything that was unused, unsafe or didn’t offer significant value.

  • Added

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

  • Changed

– Cipher Suites. – Handshake. – Hashed-Key Derivation Function (HKDF). – Key Schedule. – Sessions.

45

slide-46
SLIDE 46

THANK YOU FOR LISTENING!

slide-47
SLIDE 47

My own thoughts?

  • The Good:

– Massive efficiency gains*. – Fewer choices for Client & Server means reduced attack vectors.

  • The Bad:

– “Extensions…. extensions everywhere” (21) – A lot of added complexity for backwards compatibility. – Specification consumability is questionable.

47

* 0-RTT has a “whiff of future regret” about it.

slide-48
SLIDE 48

APPENDIX

Unused Slides

48

slide-49
SLIDE 49

What’s the point of the master secret?

  • Client and Server need:

– Keys for symmetric encryption. – Initialisation Vectors for AEAD Cipher Modes.

  • Keys & IVs generated from a master secret.
  • TLS defines a “Key Schedule”

– How HKDF algorithm is used. – How to generate an infinite amount of secure key material.

  • So, how does HKDF work?

49

slide-50
SLIDE 50

HMAC (IS THE NEW PRF)

HMAC-based Extract-and-Expand Key Derivation Function

50

slide-51
SLIDE 51

What is HKDF used for?

  • Key Schedules

– Handshake Secrets. – Early Traffic Secrets. – Master Secret. – Application Data Secrets. – Initialisation Vectors.

  • Transcript Hashes

– Certificate Verification. – Handshake “Finished” Keys.

51

slide-52
SLIDE 52

HKDF (RFC5869)
 HMAC-based Extract-and-Expand Key Derivation Function

  • TLS <= v1.2 defines PRF algorithm.

– 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 first key.

  • HMAC is integral to HKDF.

52

slide-53
SLIDE 53

Cryptographic MAC Function: HMAC

  • It creates a Message Authentication Code

using:

– Message data. – A shared key. – A cryptographic hash algorithm (set in cipher suite).

  • SHA256 or SHA384.

53

slide-54
SLIDE 54

Message Authentication Codes - Integrity

  • Keyed-Hash Message Authentication Code

54

Ight message

0x5c5c5c5c5c5c5c…

HMAC

hash XOR

XOR’d Secret Key 0x36363636363636… XOR’d Secret Key

XOR

hash

hash

slide-55
SLIDE 55

HKDF Extract & Expand

  • Extract

– Creates a Pseudo-Random Key (PRK)

Expand

– Creates infinite key material from the PRK. – Iteratively calls HMAC with an increasing counter.

55

HKDF-Expand(PRK, info, L) -> OKM T(0) = empty string (zero length) T(1) = HMAC-Hash(PRK, T(0) | info | 0x01) T(2) = HMAC-Hash(PRK, T(1) | info | 0x02) … HKDF-Extract(salt, IKM) -> PRK PRK = HMAC-Hash(salt, IKM)

slide-56
SLIDE 56

However, it’s unfortunately not that simple…

56

“tls13 “

char[6]

Label

Variable[12]

Length

enum

HashValue

Variable[255]

Messages [1]

Variable

Messages [n]

Variable

Messages [0]

Variable

Hash( )

Derive-Secret(Secret, Label, Messages[]) = HKDF-Expand( Hash.Length) Secret, ,

slide-57
SLIDE 57

Client says Hello

57

CH Parameter Description Notes Protocol Version Legacy slot for protocol version. 0x0303 TLS v1.2 Random The Client Random No more Unix time Session ID Session ID Forced 0 byte length Cipher Suites Symmetric cipher options One of Five Compression Methods N/A Must specify not supported. Supported Versions List of uint16 0x0304 (TLS v1.3) Signature Algorithms List of supported Required for Client Cert Auth Negotiated Groups Required for (EC)DHE Key Share Required for (EC)DHE Pre-Shared Key Required for PSK (incl. session resumption)

slide-58
SLIDE 58

First Contact: Client Hello

  • Client initiates the connection.
  • Contents:

– Version (Legacy)

  • Unused, must be set to 0x0303 (TLS v1.2)

– Client Random

  • Used in PRF to create master secret.

– Session ID (Legacy)

  • Ignored, kept for backwards compatibility.

– Supported Cipher Suites

  • What cipher suites this client can support.

– Compression (Legacy)

  • Ignored, kept for backwards compatibility

– Extensions (TLS v1.3)

  • List of supported TLS versions (mandatory)

– Extensions (Others)

  • Other extensions, e.g. SNI

58

slide-59
SLIDE 59

RSA Key Exchange & Forward Secrecy

  • The problem with RSA key exchange:

– The pre-master secret is always encrypted with the public certificate key in the certificate. – The certificate doesn’t change (often). – If the private key was ever compromised, Eve could read every conversation.

59

slide-60
SLIDE 60

SHA-1 & MD5 Weaknesses

  • Cryptographic hash algorithm features:

– Find any m and m’ such that hash(m)=hash(m’) – Find m’ given m such that hash(m)=hash(m’) – Find m given x such that hash(m)=x

  • MD5 vulnerabilities:

– Collision attack – done. – Theoretical attack on pre-image (2123 operations).

  • SHA-1 vulnerabilities:

– Collisions attack – given 6500 CPU-years or 1000-GPU years. – Reduced cryptographic strength from 160 bits to 77 bits.

60

slide-61
SLIDE 61

Renegotiation Attacks [RRDO10]

61