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.

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)

12. MAC-then-encrypt
12

13. 13
Valid padding TLS:
0x00
0x01, 0x01
0x02, 0x02, 0x02
etc.
MAC-then-encrypt

14. Padding
Oracle
Step 1
14

15. Padding
Oracle
Step 2
15

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

29. Käsper
Krasnov &
Gueron
Krasnov
Krasnov &
Gueron
AVX
2

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

32. AES-NI
“Stitched” implementation

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

40. https://tls13.mitm.watch/

41. Scott Helme, UK Researcher
#InfosecWebinar
@InfosecurityMag

42. The Journey to TLSv1.3
@Scott_Helme | scotthelme.co.uk
Scott Helme

44. Source: https://scotthelme.co.uk/alexa-top-1-million-analysis-february-

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-

51. Better performance
1-RTT
Handshake
0-RTT
Handshake

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)

53. Thanks!
@Scott_Helme | scotthelme.co.uk
Scott Helme

54. Questions?
@Scott_Helme | scotthelme.co.uk
Scott Helme

55. Josh Aas, Executive Director and co-founder
Let's Encrypt
#InfosecWebinar
@InfosecurityMag

56. Q&A
#InfosecWebinar
@InfosecurityMag

57. Infosecurity Magazine Webinar
#InfosecWebinar
@InfosecurityMag
Why Many Websites are still Insecure (and
How to Fix Them)
Sponsored by