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