TLS 1.3 @ 33c3

TLS 1.3 @ 33c3

The ins and outs of the new big revision of TLS, from the perspective of who deployed it.

https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad

9fdab9d005b82612cadbfe699b541f83?s=128

Filippo Valsorda

December 27, 2016
Tweet

Transcript

  1. TLS 1.3 Nick Sullivan Filippo Valsorda @grittygrease @FiloSottile

  2. 2

  3. 1994 — SSLv2 1995 — SSLv3 1999 — TLS 1.0

    2006 — TLS 1.1 2008 — TLS 1.2 … 3
  4. 4

  5. 5

  6. 6

  7. 7 Client Hello Supported cipher suites Client Server Server Hello

    Chosen cipher suite Key share Certificate & signature Key share Finished Finished HTTP GET HTTP Answer TLS 1.2 ECDHE
  8. TLS 1.2 ECDHE 8

  9. TLS 1.0, 1.1 and 1.2 are not that different TLS

    1.3 is a BIG jump 9
  10. RTT--; 10

  11. 11 Client Hello Supported AEAD / groups / signatures Key

    share Server Hello Chosen AEAD Key share Finished Certificate & signature Finished HTTP GET HTTP Answer TLS 1.3 Client Server
  12. TLS 1.3 12

  13. 13 Client Hello Supported AEAD / groups / signatures Key

    share Hello Retry Request Chosen group Cookie Hello Retry Request Client Server Client Hello Cookie Other key share Server Hello Chosen AEAD Key share Certificate & signature Finished …
  14. Resumption “Hey, I know you!” 14

  15. 15 Client Hello Supported cipher suites Client Server Server Hello

    Session ID Key share Finished Finished HTTP GET HTTP Answer TLS 1.2 ECDHE New Session Ticket
  16. 16 Client Hello Session ID / Ticket Server Hello Finished

    Finished HTTP GET HTTP Answer TLS 1.2 Resumption Client Server
  17. 17 Client Hello Session Ticket (PSK) Server Hello Finished TLS

    1.3 Resumption Client Server Finished HTTP GET HTTP Answer
  18. 18 Client Hello Session Ticket (PSK) Forward Secrecy Client Server

    Decrypt this with the session ticket key Server Hello Finished Finished HTTP GET HTTP Answer
  19. 19 Client Hello Session Ticket (PSK) Key share PSK-ECDHE Client

    Server Finished HTTP GET HTTP Answer Server Hello Key share Finished
  20. 0-RTT! 20

  21. 21 Client Hello Session Ticket (PSK) Key share Server Hello

    Key share Finished HTTP GET HTTP Answer 0-RTT Client Server Finished
  22. 0-RTT! But… 22

  23. 0-RTT 23 No PSK-ECDHE

  24. 24 Client Hello Session Ticket (PSK) Key share Server Hello

    Key share Finished HTTP GET HTTP Answer Client Server Finished Forward secret from here 0-RTT w/ ECDHE
  25. TLS 1.2 is forward secret: • Relatively to the certificate:

    always (using ECDHE) • Relatively to the ticket key: never 25 TLS 1.3 is forward secret: • Relatively to the certificate: always • Relatively to the ticket key: except 0-RTT early data (w/ PSK-ECDHE)
  26. 0-RTT 26 Replays

  27. 27 Client Hello Session Ticket (PSK) Key share HTTP GET

    0-RTT replay Client Hello Session Ticket (PSK) Key share HTTP GET
  28. obfuscated_ticket_age • The client sends the age in milliseconds of

    the ticket • The server checks it matches its view, with some leeway • Obfuscated with a ticket_age_add value sent as part of the New Session Ticket message struct { opaque identity<1..2^16-1>; uint32 obfuscated_ticket_age; } PskIdentity; 28
  29. 29 0-RTT confirmation Client Hello Session Ticket (PSK) Key share

    Server Hello Key share Finished HTTP POST Finished HTTP POST HTTP Answer
  30. max_early_data_size • The server must either accept or reject the

    early data, entirely, without knowing how much there will be • If it accepts it and can’t process it, it must buffer it • Once the Finished comes, all early data is confirmed • max_early_data_size limits the buffer size • Devised with Drew Springall 30
  31. It’s the application’s responsibility 31 Protocols MUST NOT use 0-RTT

    data without a profile that defines its use.
  32. It’s the API’s responsibility 32 • Default to 1-RTT •

    Allow the server to reject / wait for the Finished • Let the client to decide what to send in the early data
  33. HTTP and 0-RTT 33 • Utopia: GET is idempotent! •

    Reality: nope. GET /send_money.php?to=filippo&amount=1000
  34. HTTP and 0-RTT 34 • Utopia: GET is idempotent! •

    Reality: nope.
  35. HTTP and 0-RTT 35

  36. 36 Complexity Benefit

  37. No Forward Secrecy 37 Client Hello Supported cipher suites Server

    Hello Chosen cipher suite Certificate encrypted with Certificate Public Key Finished Finished TLS 1.2 Static RSA mode
  38. To: IETF TLS 1.3 Working Group Members My name is

    Andrew Kennedy and I work at BITS, the technology policy division of the Financial Services Roundtable (http://www.fsroundtable.org/bits). My organization represents approximately 100 of the top 150 US-based financial services companies including banks, insurance, consumer finance, and asset management firms. [...] Deprecation of the RSA key exchange in TLS 1.3 will cause significant problems for financial institutions, almost all of whom are running TLS internally and have significant, security-critical investments in out-of-band TLS decryption. [...] 38
  39. 39 Out-of-band TLS decryption? Yes, please!

  40. Hi Andrew, My view concerning your request: no. Rationale: We're

    trying to build a more secure internet. Meta-level comment: You're a bit late to the party. We're metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans. More exactly, we are at draft 15 and RSA key transport disappeared from the spec about a dozen drafts ago. I know the banking industry is usually a bit slow off the mark, but this takes the biscuit. Cheers, Kenny 40
  41. None
  42. None
  43. RC4

  44. 3DES

  45. MD5 & SHA1 SLOTH 2016

  46. AES-CBC Vaudenay 2002 Boneh/Brumley 2003 BEAST 2011 Lucky13 2013 POODLE

    2014 Lucky Microseconds 2015
  47. RSA-PKCS1-1.5 Bleichenbacher 1998(!!) Jager 2015 DROWN 2016

  48. Compression CRIME 2012

  49. Renegotiation Marsh Ray Attack 2009 Renegotiation DoS 2011 Triple Handshake

    2014 Replaced with lightweight key update
  50. Lucky 13 RC4 Weakness POODLE Vaudenay Padding Oracle BEAST CRIME

    BREACH WeakDH FREAK SLOTH Lucky Microseconds DROWN LogJam
  51. 51 & Fortify

  52. None
  53. TLS 1.2 Certificate Authentication • Cipher negotiation protected by Finished

    Message (MAC) • MAC algorithm determined by cipher negotiation • FREAK, LogJam, CurveSwap: choose weak parameters 53
  54. 54 Client Hello Supported cipher suites Client Server Server Hello

    Chosen cipher suite Key share Certificate & signature Key share Finished Finished HTTP GET HTTP Answer TLS 1.2 ECDHE NOT SIGNED
  55. 55 Client Hello Supported AEAD / groups / signatures Key

    share Server Hello Chosen AEAD Key share Finished Certificate Signature Finished HTTP GET HTTP Answer TLS 1.3 Client Server }
  56. Fewer, better choices • Key Exchange, Cipher, Authentication negotiated separately

    • No arbitrary DH groups • No arbitrary curves 56
  57. None
  58. None
  59. None
  60. Safer Resumption TLS 1.2 tickets • Current session keys encrypted

    with session ticket key • Session ticket key compromise a risk for all connections TLS 1.3 tickets • Next session keys encrypted with session ticket key • Session ticket key compromise only risk for resumed connections 60
  61. 61 Client Hello Supported cipher suites Client Server Server Hello

    Session ID Key share Finished Finished HTTP GET HTTP Answer TLS 1.2 ECDHE New Session Ticket Unencrypted
  62. Formal Verification • Tamarin (Oxford, Royal Holloway) • ProScript-TLS, miTLS

    (INRIA) • nqsb-TLS (Cambridge) 62
  63. Standards The IETF way 63

  64. 64

  65. Timeline • First Draft: April 17, 2014 • 3Shake, POODLE,

    FREAK, LogJam, DROWN, Lucky Microseconds, SLOTH, more… • Draft 18: October 26, 2016 • Final draft: February, 2017 (we hope) • TLS 1.2: 79 pages • TLS 1.3: 81 pages (minus references and appendices) 65
  66. 66 Github + Mailing List

  67. Key Schedule • Inspired by QUIC crypto • Semi-static DH

    key shared out of band • Tree-based key schedule 67
  68. 0 | v PSK -> HKDF-Extract | +-----> Derive-Secret() =

    early_traffic_secret | v (EC)DHE -> HKDF-Extract | +-----> Derive-Secret() = handshake_traffic_secret | v 0 -> HKDF-Extract | +-----> Derive-Secret() = traffic_secret_0 | +-----> Derive-Secret() = resumption_master_secret
  69. What's in a name? Is it TLS 1.3, TLS 2,

    TLS 2.0, TLS 4, TLS 7, TLS 2017? 69
  70. 70

  71. Version Intolerance • Wire versions • SSL 3.0: 3.0 •

    TLS 1.0: 3.1 • TLS 1.1: 3.2 • TLS 1.2: 3.3 • TLS 1.3: 3.4 ??? • Servers are intolerant of 3.4 • >2% of servers fail connection • Solution: “3.3” in ClientHello,
 real versions in extension • GREASE by David Benjamin 71
  72. Version Intolerance 72

  73. Implementation Getting our hands dirty 73

  74. IETF 95 Hackathon - April 2016 • NSS (C): Martin

    Thomson and Eric Rescorla • Mint (Go): Richard Barnes and Nick Sullivan Result: Firefox was able to load https://tls13.cloudflare.com! 74
  75. 75 • Based on Go crypto/tls • Server only •

    Audited
  76. https://go-review.googlesource.com/q/branch:+dev.tls 76

  77. Deploying is hard 77 • First deployed Tris: draft 13

    • Supported multiple drafts at a time (“hybrids”) • Browsers sometimes… diverged
  78. 78

  79. You may already be using it • Firefox Nightly •

    Chrome Beta (50%) / Canary 79
  80. 80 Chrome Field Test Firefox Nightly Cloudflare Launch

  81. Nick Sullivan Filippo Valsorda @grittygrease @FiloSottile https://tlswg.github.io/tls13-spec/ https://github.com/cloudflare/tls-tris https://blog.cloudflare.com/tag/tls-1-3/

  82. Y U NO ENCRYPT SNI!? 82

  83. 83 Client Hello SNI Key share Server Hello Key share

    Certificate & signature Finished TLS 1.3 can’t encrypt SNI No key negotiated yet Already has to pick certificate