Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tls 13final13

242 views

Published on

The talk first walks over some of the security issues of the older versions of the SSL/TLS protocol. Then It introduces the upcomint TLS 1.3 version, presenting its new features and adoption status.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Tls 13final13

  1. 1. Vít zslav ížekě Č vcizek@suse.com Introduction to TLS 1.3
  2. 2. About me ● Open Source Developer ● Software Engineer at SUSE – Mostly C programming – Member of Emergency Update Team – Maintainer of OpenSSL, GnuTLS and mod_nss
  3. 3. Agenda ● What’s TLS ● What’s different in TLS 1.3 ● TLS 1.3 adoption
  4. 4. What is TLS
  5. 5. What is Transport Layer Security ● cryptographic protocol providing a secure connection over computer networks ● Widely used on the Internet – HTTP, Email, VPN, VoIP, etc ● Client-Server architecture ● Utilizes Public Key Infrastructure
  6. 6. Properties of the Secure Connection ● Authentication – Public Key Cryptography – Mandatory for the server ● Confidentiality – Transmitted data is private to the peers ● Integrity – Sent data cannot be modified
  7. 7. TLS Components ● Handshake protocol (interesting) – Establish shared keys – Negotiate parameters – Authenticate peers ● Record protocol (boring) – Data transmission
  8. 8. Handshake (TLS 1.2) ● Shared secret exchanged using DHE ● Random nonces and shared secret mixed into a master secret ● All keys are derived from master secret
  9. 9. TLS Security Issues
  10. 10. Brief history of TLS ● SSL 2.0: *1995, †2011 (RFC 6176) ● SSL 3.0: *1996, †2015 (RFC 7568) ● TLS 1.0: *1999 (RFC 2246) ● TLS 1.1: *2006 (RFC 4346) ● TLS 1.2: *2008 (RFC 5246) ● TLS 1.3: *2018 (Proposed Standard)
  11. 11. SSL 2.0 deficiencies ● Sessions terminated by the end of TCP connection – Injected TCP FIN is indistinguishable from a legimate end of the session ● Handshake messages are not protected – MitM can trick the client into picking a weaker cipher suite ● Weak MAC (MD5) ● MAC and encryption use the same key – Problem with a weak encryption algorithm ● Missing functionality (PFS, Extensions, etc)
  12. 12. SSL 3.0 ● Killed by a dog! ● Do you know which one?
  13. 13. POODLE Attack (CVE­-2014­-3566) ● Padding Oracle on Downgraded Legacy Encryption ● Exploits CBC encryption mode – Padding is non-deterministic and not covered by MAC ● No more secure ciphers in SSL 3.0
  14. 14. SSL 3.0 Issues ● No suitable ciphers – AES CBC broken (POODLE) – RC4 is weak and biased ● MAC-then-encrypt used in CBC mode ● Key Exchange vulnerable to MitM – Renegotiation attack – Triple Handshake (session resumption) ● Weak hash functions SHA-1 and MD5 ● Custom Cryptographic Primitives (risky) ● Missing functionality – TLS Extensions are used to address the issues on the left
  15. 15. Some attacks agains TLS ● CBC – BEAST, POODLE, Lucky Microseconds ● Mac-Then-Encrypt – Lucky 13 ● Compression – CRIME, TIME, BREACH ● RSA – Bleichenbacher, Klíma, ROBOT, BERserk, FREAK ● RC4 – RC4 No More, Bar-Mitzvah ● MD5/SHA1 – SLOTH ● Renegotiation – Triple Handshake, CVE-2009-3555
  16. 16. Other Security Issues ● Implementation bugs – Heartbleed, BERserk, SMACK – Hundreds of CVEs ● Weak cryptography – LOGJAM, (FREAK, Curveswap)
  17. 17. More information about TLS security ● RFC 7457: Summarizing Known Attacks on TLS and DTLS ● RFC 7525: Recommendations for Secure Use of TLS and DTLS
  18. 18. TLS 1.3
  19. 19. TLS 1.3 Standard Development ● Lead by IETF ● Initiated in Spring 2014 ● GitHub: https://github.com/tlswg/tls13-spec ● Mailing List: tls@ietf.org
  20. 20. TLS 1.3 development ● More open to the community ● Several independent implementations ● Formal verification
  21. 21. TLS 1.3 Design Goals (by Eric Rescorla) ● Clean-up – Remove unused and obsolete stuff ● Security – Use modern cryptography ● Privacy – Encrypt more of the protocol ● Performance – Speed up the handshake ● Continuity – Maintain existing use cases
  22. 22. Half of the presentation ● Still awake? Good! ● More interesting stuff coming :-)
  23. 23. Clean-Up
  24. 24. Clean-up Victims ● Custom DHE groups – Servers guessing acceptable client size – Unused for ECDHE ● Point formats negotiation – Mostly uncompressed formats used ● DSA ● “Obscure” ciphers (Camellia) ● Renegotiation
  25. 25. Protocol Simplification ● Simplified handshake state machine ● Session resumption merged with PSK ● Renegotiation removed and replaced
  26. 26. Renegotiation ● Complicated, source of several vulnerabilities (3Handshake) ● Key Update – Simple post-handshake message – New keys derived from the old keys by HKDF ● Post-Handshake Authentication – Server prompts client for a certificate
  27. 27. Better Security
  28. 28. Security Victims ● Compression ● Export Ciphers ● Static RSA Key Exchange – Slow, not PFS ● RSA-PKCS15 ● Non-AEAD ciphers ● Static DH removed – Not PFS
  29. 29. Compression ● CBC – BEAST, POODLE, Lucky Microseconds ● Mac-Then-Encrypt – Lucky 13 ● Compression – CRIME, TIME, BREACH ● RSA – Bleichenbacher, Klíma, ROBOT, BERserk, FREAK ● RC4 – RC4 No More, Bar-Mitzvah ● MD5/SHA1 – SLOTH ● Renegotiation – Triple Handshake, CVE-2009-3555
  30. 30. Non-AEAD ciphers ● CBC – BEAST, POODLE, Lucky Microseconds ● Mac-Then-Encrypt – Lucky 13 ● Compression – CRIME, TIME, BREACH ● RSA – Bleichenbacher, Klíma, ROBOT, BERserk, FREAK ● RC4 – RC4 No More, Bar-Mitzvah ● MD5/SHA1 – SLOTH ● Renegotiation – Triple Handshake, CVE-2009-3555
  31. 31. RSA ● CBC – BEAST, POODLE, Lucky Microseconds ● Mac-Then-Encrypt – Lucky 13 ● Compression – CRIME, TIME, BREACH ● RSA – Bleichenbacher, Klíma, ROBOT, BERserk, FREAK ● RC4 – RC4 No More, Bar-Mitzvah ● MD5/SHA1 – SLOTH ● Renegotiation – Triple Handshake, CVE-2009-3555
  32. 32. Overall ● CBC – BEAST, POODLE, Lucky Microseconds ● Mac-Then-Encrypt – Lucky 13 ● Compression – CRIME, TIME, BREACH ● RSA – Bleichenbacher, Klíma, ROBOT, BERserk, FREAK ● RC4 – RC4 No More, Bar-Mitzvah ● MD5/SHA1 – SLOTH ● Renegotiation – Triple Handshake, CVE-2009-3555
  33. 33. TLS 1.3 cipher suites ● Authentication and key exchange separated from cipher negotiation ● Authentication – Certificate/PSK ● Key exchange – ECDHE/DHE
  34. 34. TLS 1.2 and 1.3 ciphers ● Key exchange, Authentication, Encryption, MAC ● TLS 1.2 – TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 ● TLS 1.3 – TLS_AES_256_GCM_SHA384
  35. 35. The short TLS 1.3 ciphers list ● TLS13-AES-256-GCM-SHA384 ● TLS13-CHACHA20-POLY1305-SHA256 ● TLS13-AES-128-GCM-SHA256 ● TLS13-AES-128-CCM-8-SHA256 ● TLS13-AES-128-CCM-SHA256
  36. 36. TLS 1.3 Crypto overview ● Key Exchange – Elliptic Curves: P-256, P-384, P-521, x25519, x448 – Finite Field (DHE) ● Authentication – RSA, ECDSA, EdDSA ● Encryption – AEAD only (AES-GCM, ChaCha20/Poly1305) – Cipher TLS_AES_128_GCM_SHA256 mandatory
  37. 37. TLS 1.3 Crypto Summary ● A few, but good choices ● Just 5 ciphersuites (1 mandatory) ● One EC point format
  38. 38. Speed-up
  39. 39. Handshake Speed-up ● 1 round trip “lighter” than TLS 1.2 in most cases ● Full Handshake (1-RTT) ● Resumption (0-RTT)
  40. 40. Full Handshake (1.2 vs 1.3)
  41. 41. TLS 1.3 ● Tries to be optimistic – Goes hand in hand with the reduced list of options ● Client guesses server parameters and sends a key_share on first flight ● key_share can contain more groups ● What happens when the speculation goes wrong?
  42. 42. TLS 1.3 – Worst Case ● Server didn’t like the client’s key_share ● Sends its own key_share based on supported client groups
  43. 43. Resumed Handshake (1.2 vs 1.3)
  44. 44. Perfect Forward Secrecy ● TLS 1.2 – Server certificate ● DHE ciphers: YES ● Other ciphers: NO – Pre-Shared Key ● NO ● TLS 1.3 – Server certificate ● YES (all ciphers are DHE) – Pre-Shared Key ● PSK-ECDHE: YES (except EarlyData) ● PSK-only: NO
  45. 45. 1-RTT: Can we do better? ● 0-RTT Early Data!
  46. 46. TLS 1.3 with 0-RTT ● Early data encrypted with the PSK ● Not forward secret ● Needs application support
  47. 47. O-RTT: EarlyData ● Upon receiving 0-RTT EarlyData a server can: – Ignore it and return 1-RTT response – Request a new CH by HRR and skip all Application Data – Send early_data in encrypted extensions, signalling that it'll process it ● TLS implementations shouldn't resend early data, and mustn't ● resend them if ALPN differs in negotiated connection ● After server's Finished, EndOfEarlyData indicates key change
  48. 48. Replay Attack! ● Attacker can replay the Early Data
  49. 49. EarlyData Anti-Replay Protection ● Mitigation: saving state and allow the 0-RTT data accepted once ● Problem sharing the state when the servers are geographically spread – No globally consistent server state ● Servers should ensure that any server accepts 0-RTT for the same 0-RTT handshake at most once
  50. 50. EarlyData Replay Attacks ● The Replays can’t be avoided, only limited – Attacker could be fast enough – No consistent state across all the servers ● Applications have to count with it – Allow only idempotent requests (HTTP Get)
  51. 51. More Privacy
  52. 52. Traffic analysis countermeasures ● More parts of the Handshake are encrypted – Server certificate ● Record content type encrypted – 23 (application data) – True content type hidden encrypted ● Arbitrary padding ● SNI – Proposal using Front/Hidden via 0-RTT data
  53. 53. Compatibility
  54. 54. Middleboxes ● Machines that examine TLS traffic – MitM the TLS connection ● Middleboxes don’t like new versions – version 0x0304 means disconnect ● Solution: Make TLS 1.3 look like TLS 1.2 resumption
  55. 55. TLS 1.3 Camouflage ● KeyShare, supported_versions, PSK are extensions ● HRR looks like ServerHello, distinguished by Random field – Random set to SHA-256 of "HelloRetryRequest" ● Real protocol version in supported_version extension ● session_id and compression restored back in ServerHello ● Dummy Change Cipher Spec (CCS) ● GREASE mechanism
  56. 56. TLS 1.3 pitfalls ● TLS 1.3 ciphers incompatible with TLS 1.2 – OpenSSL cipher string "ECDHE" won't match any TLS 1.3 ciphersuites ● Sessions are established after the handshake ● DSA certificate aren't allowed any more ● Renegotiation results in a terminated connection ● Compression also not allowed
  57. 57. TLS 1.3 Adoption
  58. 58. TLS 1.3 status ● Draft 28 approved as Proposed Standard by IETF ● Will become an RFC soon
  59. 59. TLS Libraries ● OpenSSL: will be in 1.1.1 ● GnuTLS: will be in 3.6.3 ● NSS: yes ● SChannel (Microsoft): not yet ● Secure Transport (Apple): yes
  60. 60. Web Browsers ● Chrome: yes, enabled since 65 ● Firefox: yes, gradually being enabled – check your security.tls.version.max ● Safari: yes, off by default ● Edge: no, in development
  61. 61. Web servers ● Apache – mod_ssl: no – mod_nss: yes, since 1.0.17 ● Nginx: yes, 1.13 ● IIS: no
  62. 62. Other Applications ● Wireshark
  63. 63. close_notify ● Questions?
  64. 64. Links ● TLS 1.3 Draft 28: https://tools.ietf.org/html/draft-ietf-tls-tls13-28 ● Summarizing Known Attacks on TLS: https://tools.ietf.org/html/rfc7457 ● Recommendations for Secure Use of Transport Layer Security (TLS) ● https://tools.ietf.org/html/rfc7525 ● https://tools.ietf.org/html/rfc7525 ● https://tools.ietf.org/html/rfc7525
  65. 65. License This slide deck is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license. It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any derivative work is distributed under the same license. Details can be found at https://creativecommons.org/licenses/by-sa/4.0/ General Disclaimer This document is not to be construed as a promise by any participating organisation to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for openSUSE products remains at the sole discretion of openSUSE. Further, openSUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All openSUSE marks referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States and other countries. All third-party trademarks are the property of their respective owners. Credits Template Richard Brown rbrown@opensuse.org Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/

×