Why Many Websites are still Insecure (and How to Fix Them)
1 like1,204 views
This document summarizes a webinar discussing why many websites are still insecure and how to fix them. The webinar featured presenters from Cloudflare, Let's Encrypt, and independent researchers. They discussed issues with previous TLS standards like POODLE attacks and server intolerance leading to slow TLS 1.2 adoption. TLS 1.3 aims to address vulnerabilities and improve adoption. Presenters also dispelled myths about cryptography being too expensive now, noting free certificates and faster modern cryptography. Attendees were encouraged to help promote HTTPS adoption and monitor TLS 1.3 implementation.
Why Many Websites are still Insecure (and How to Fix Them)
- 1. Infosecurity Magazine Webinar #InfosecWebinar @InfosecurityMag Why Many Websites are still Insecure (and How to Fix Them) Sponsored by
- 2. Moderator Dan Raywood, Contributing Editor Infosecurity Magazine #InfosecWebinar @InfosecurityMag
- 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. Nick Sullivan Head of Cryptography Cloudflare #InfosecWebinar @InfosecurityMag & Vlad Krasnov System Engineer Cloudflare
- 5. Why Many Websites are still Insecure (and How to Fix Them)
- 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. HTTPS = HTTP + Security • Transport Layer Security (TLS) • Data encryption and integrity • Server authentication • Negotiation of keys happens in the “handshake” 7
- 8. 1994 1998 2002 2010 20142006 2018 SSLv1 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3
- 9. What have been problems with TLS?
- 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. Padding Oracles 11 CBC mode (POODLE, BEAST, Lucky 13) RSA Key Exchange (ROBOT)
- 13. 13 Valid padding TLS: 0x00 0x01, 0x01 0x02, 0x02, 0x02 etc. MAC-then-encrypt
- 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. 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. Why TLS 1.2 was so slow to be adopted
- 19. Dec 2015Feb 2014May 2012 Data: SSL Pulse
- 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. 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. What problems and vulnerabilities did TLS 1.3 address?
- 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. Will TLS 1.3 adoption be faster than that of TLS 1.2?
- 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. The “expensive” crypto myth
- 27. Is it really a myth? This is the new style. ● Yes … today ● Not so a few years ago
- 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
- 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. “Encryption is slow” ● Historically: ○ RC4 ○ 3DES ○ AES-CBC ● Today: ○ AES-GCM ○ CHACHA20-POLY1305
- 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!
- 36. “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
- 37. “Certificates cost money and are hard to manage” ● Free certificates by Let’s Encrypt and others ● Easy to manage and automate ○ ACME
- 38. 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
- 39. How you can help solve this problem
- 41. Scott Helme, UK Researcher #InfosecWebinar @InfosecurityMag
- 42. The Journey to TLSv1.3 @Scott_Helme | scotthelme.co.uk Scott Helme
- 45. Source:
- 46. Source:
- 47. TLSv1.2 • HTTP/2 has many benefits • Brotli Compression • SEO++ • Powerful Features (geolocation et al.) • Referrer Data • Session Resumption • HTTP Bad
- 48. 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
- 49. TLSv1.3 is more complex TLSv1.3 is also simpler TLSv1.3
- 50. 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-
- 52. 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)
- 55. Josh Aas, Executive Director and co-founder Let's Encrypt #InfosecWebinar @InfosecurityMag
- 57. Infosecurity Magazine Webinar #InfosecWebinar @InfosecurityMag Why Many Websites are still Insecure (and How to Fix Them) Sponsored by