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.

Why Many Websites are still Insecure (and How to Fix Them)

1,025 views

Published on

The latest version of the transport layer security (TLS) protocol was launched at the end of 2017, and version 1.3 proposes the largest change with improvements to performance and security. However, there has not been widespread adoption of this protocol which leaves many users exposed to data and privacy breaches. In this webinar, we will look at the new developments in TLS and SSL, why the internet needs better security and the technical challenges of good encryption.

Published in: Technology
  • Be the first to comment

Why Many Websites are still Insecure (and How to Fix Them)

  1. 1. Infosecurity Magazine Webinar #InfosecWebinar @InfosecurityMag Why Many Websites are still Insecure (and How to Fix Them) Sponsored by
  2. 2. Moderator Dan Raywood, Contributing Editor Infosecurity Magazine #InfosecWebinar @InfosecurityMag
  3. 3. Nick Sullivan, Head of Cryptography, Cloudflare Vlad Krasnov, System Engineer Cloudflare Scott Helme, UK Researcher Josh Aas, Executive Director and co-founder Let's Encrypt #InfosecWebinar @InfosecurityMag
  4. 4. Nick Sullivan Head of Cryptography Cloudflare #InfosecWebinar @InfosecurityMag & Vlad Krasnov System Engineer Cloudflare
  5. 5. Why Many Websites are still Insecure (and How to Fix Them)
  6. 6. ● What have been problems with TLS? ● Why TLS 1.2 was so slow to be adopted ● What problems and vulnerabilities did TLS 1.3 address? ● Will TLS 1.3 adoption be faster than that of TLS 1.2? ● The expensive “crypto” myth ● How you can help solve this problem Agenda
  7. 7. HTTPS = HTTP + Security • Transport Layer Security (TLS) • Data encryption and integrity • Server authentication • Negotiation of keys happens in the “handshake” 7
  8. 8. 1994 1998 2002 2010 20142006 2018 SSLv1 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3
  9. 9. What have been problems with TLS?
  10. 10. 1994 1998 2002 2010 20142006 2016 SSLv1 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 SSLv2 Broken SSLv3 Broken (POODLE) Vaudenay Padding Oracle Boney/Brumley Padding Oracle MD5 CA BEAST CRIME BREACH RC4 Lucky 13 LogJam WeakDH Bleichenbacher e=3 Heartbleed BERserk FREAK SLOTH DROWN
  11. 11. Padding Oracles 11 CBC mode (POODLE, BEAST, Lucky 13) RSA Key Exchange (ROBOT)
  12. 12. MAC-then-encrypt 12
  13. 13. 13 Valid padding TLS: 0x00 0x01, 0x01 0x02, 0x02, 0x02 etc. MAC-then-encrypt
  14. 14. Padding Oracle Step 1 14
  15. 15. Padding Oracle Step 2 15
  16. 16. POODLE 16 Padding oracle and a downgrade attack • Downgrade dance (thanks browsers!) • Line things up so that padding is in last block • Swap target block with padding block • Around 256 guesses per byte
  17. 17. 1994 1998 2002 2010 20142006 2018 SSLv1 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3 SSLv2 Broken SSLv3 Broken (POODLE) Vaudenay Padding Oracle Boney/Brumley Padding Oracle MD5 CA BEAST CRIME BREACH RC4 Lucky 13 LogJam WeakDH Bleichenbacher e=3 Heartbleed BERserk FREAK
  18. 18. Why TLS 1.2 was so slow to be adopted
  19. 19. Dec 2015Feb 2014May 2012 Data: SSL Pulse
  20. 20. Google • Chrome 30 and later • Google Android Browser for Android 5.0 and later Mozilla: • Firefox 27 and and later Microsoft: • Internet Explorer 11 and later • Internet Explorer Mobile 11 and later • Microsoft Edge all versions Apple • Safari on OS X 10.9 and later • Safari on iOS 5 and later TLS 1.2 Client Support
  21. 21. TLS 1.2 had problems being deployed due to server intolerance. Some servers would disconnect rather than downgrade if a TLS 1.2 client connected. This led to the deployment of insecure downgrades, which led to POODLE. 2 1
  22. 22. What problems and vulnerabilities did TLS 1.3 address?
  23. 23. TLS 1.3 Remove support for ● weak ciphers (3DES, RC4) ● weak cipher modes (CBC) ● weak public key modes (Static RSA, RSA-PKCS#1v1.5) ● insecure downgrade (POODLE) ● Insecure renegotiation modes (Triple Handshake) 2 3
  24. 24. Will TLS 1.3 adoption be faster than that of TLS 1.2?
  25. 25. TLS 1.3 was tested in production before finalizing the specification. Server intolerance was found, along with middlebox intolerance. The specification was modified to be more friendly (read: it looks a lot like 1.2 to intolerant implementations) The concept of GREASE was introduced to prevent future intolerance. TLS 1.2 had problems being deployed due to server intolerance
  26. 26. The “expensive” crypto myth
  27. 27. Is it really a myth? This is the new style. ● Yes … today ● Not so a few years ago
  28. 28. “Key exchange is slow” ● Historically: RSA ○ Even 1024-bit RSA was very, very slow on 32-bit systems ○ First x86-64 server in 2003 (Opteron) ○ Took years for ecosystem to catch up ■ First 64-bit Windows in 2005 ■ x86_64 Montgomery Multiplication added to OpenSSL in 2005 ● DSA was faser, but never caught up ● No ECDSA ○ Technically supported since TLS 1.0 (1999!) ○ Suite B in 2005 ■ Patents ■ No CA support, more expensive ● Symantec (and others) added ECDSA in 2013, only with their “premium” certificates
  29. 29. Käsper Krasnov & Gueron Krasnov Krasnov & Gueron AVX 2
  30. 30. ECDSA with ECDHE! ● Supported by all browsers today ● ECC certificates are available for FREE! ○ Let’s Encrypt ● Use with P256 or x25519 ECDHE key exchange
  31. 31. “Encryption is slow” ● Historically: ○ RC4 ○ 3DES ○ AES-CBC ● Today: ○ AES-GCM ○ CHACHA20-POLY1305
  32. 32. AES-NI “Stitched” implementation
  33. 33. “TLS adds round trips” ● Full TLS1.2 handshake adds 2 round trips ● Only 1 round trip with resumption ○ Tickets ○ Session ID ● Full TLS1.3 handshake only adds 1 round trip ● Option for 0 round trip ● Also round trips today can be made much shorter ○ Deploy in any geography ○ Use a CDN!
  34. 34. “TLS adds overhead to the network” ● Record framing ○ Smaller overhead when using AES-128-GCM ● Handshake ○ Smaller overhead when using x25519 + ECDSA ○ Certificate compression in TLS 1.3 ● In addition to compensate over TLS ○ Enable HTTP/2 with HPACK header compression ○ Enable Brotli compression
  35. 35. “Certificates cost money and are hard to manage” ● Free certificates by Let’s Encrypt and others ● Easy to manage and automate ○ ACME
  36. 36. A look into the future - Post Quantum ● Currently a “competition” is held by NIST ● Some good implementation ● Size vs. speed tradeoffs ○ E.g. NewHope very fast, large key exchange ○ E.g. SIKE, slower but small key exchange ● Good idea to start incorporating in KX today, for PFS ● Eventually signatures would have to evolve too
  37. 37. How you can help solve this problem
  38. 38. https://tls13.mitm.watch/
  39. 39. Scott Helme, UK Researcher #InfosecWebinar @InfosecurityMag
  40. 40. The Journey to TLSv1.3 @Scott_Helme | scotthelme.co.uk Scott Helme
  41. 41. Source: https://scotthelme.co.uk/alexa-top-1-million-analysis-february-
  42. 42. Source:
  43. 43. Source:
  44. 44. TLSv1.2 • HTTP/2 has many benefits • Brotli Compression • SEO++ • Powerful Features (geolocation et al.) • Referrer Data • Session Resumption • HTTP Bad
  45. 45. Additional Support • Content-Security-Policy • upgrade-insecure-requests • CSP Reporting (mixed-content) • Strict-Transport-Security • Default HTTPS • Hard fail certificate errors • Saves redirects on the wire
  46. 46.  TLSv1.3 is more complex  TLSv1.3 is also simpler TLSv1.3
  47. 47. All cipher suites TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SH A256 TLS_AES_128_CCM_SHA256 TLS_AES_128_CCM_8_SHA256 Source: https://tools.ietf.org/html/draft-ietf-tls-tls13-
  48. 48. Better performance 1-RTT Handshake 0-RTT Handshake
  49. 49. Improved Forward Secrecy Server key - Forward Secrecy (optional in TLSv1.2) Ticket key - Forward Secrecy (not in TLSv1.2) Early data - No Forward Secrecy (n/a in TLSv1.2)
  50. 50. Thanks! @Scott_Helme | scotthelme.co.uk Scott Helme
  51. 51. Questions? @Scott_Helme | scotthelme.co.uk Scott Helme
  52. 52. Josh Aas, Executive Director and co-founder Let's Encrypt #InfosecWebinar @InfosecurityMag
  53. 53. Q&A #InfosecWebinar @InfosecurityMag
  54. 54. Infosecurity Magazine Webinar #InfosecWebinar @InfosecurityMag Why Many Websites are still Insecure (and How to Fix Them) Sponsored by

×