Secure communications are one of the most important topics in information security, and the Transport Layer Security (TLS) protocol is currently the most used protocol to provide secure communications on the internet. For example, when you are connecting to your online banking application, your favorite instant message application or social networks, all those communications are being transmitted using TLS. With TLS, the information sent by the browser and the service is secured and encrypted, meaning that the information cannot be modified or tampered with by an attacker. The communications are also verified to ensure that the browser is connected to the right endpoint (e.g. Wikipedia). Presentation, called “Playback: A TLS 1.3 Story,” about some of the known security implications of using 0-RTT and will show proof of concepts of some attacks that have been seen in real-world environments. Attendees will learn about TLS 1.3 0-RTT, see some examples about how an attacker could take advantage of that new feature and get an understanding of the security implications of enabling the feature and how it could be used safely minimizing any potential security impacts. Speakers:  Alfonso García Alguacil, Senior Penetration Tester at Cisco Alejo Murillo Moya, Red Team Lead EMEAR @ Cisco

1. PLAYBACK: A TLS 1.3 STORY

2. WHO ARE WE?
Alfonso García Alguacil Alejo Murillo Moya

3. INTRODUCING TLS 1.3
The Good
• KISS – Only 5 ciphers supported

4. INTRODUCING TLS 1.3
The Good
• No vulnerable to the attacks impacting
previous versions

5. INTRODUCING TLS 1.3
The Good
• Welcome Forward Secrecy

6. INTRODUCING TLS 1.3
The Good
• Formal security analysis performed to
the protocol

7. INTRODUCING TLS 1.3
The Bad
• Protocol tainted due to “compatibility
issues” 

8. INTRODUCING TLS 1.3
The Ugly
• 0-RTT (this talk )

9. 0-RTT: SPEED AT A COST
VS

11. Your browsers…
… and CDNs may
already be supporting
TLS 1.3 0-RTT!
… implementations …
BoringSSL

12. TLS 1.3 HANDSHAKE

13. TLS 1.3 HANDSHAKE

14. TLS 1.3 HANDSHAKE

15. TLS 1.3 HANDSHAKE

16. TLS 1.3 0-RTT

17. TLS 1.3 0-RTT

18. TLS 1.3 0-RTT

19. As you can see…
it may be possible to do REPLAY
REPLAY attacks!
REPLAY
REPLAY
REPLAY

20. TLS 1.3 0-RTT REPLAY

21. TLS 1.3 0-RTT REPLAY

22. TLS 1.3 0-RTT REPLAY

23. TLS 1.3 0-RTT REPLAY

24. TLS 1.3 0-RTT REPLAY

25. ANTI-REPLAY PROTECTIONS
Single-Use Tickets
Single-Use Tickets

26. ANTI-REPLAY PROTECTIONS
Single-Use Tickets
Single-Use Tickets
Client-Hello Recording

27. ANTI-REPLAY PROTECTIONS
Single-Use Tickets
Single-Use Tickets
Client-Hello Recording
“Freshness” checks

28. ANTI-REPLAY PROTECTIONS
Single-Use Tickets
Single-Use Tickets
Client-Hello Recording
“Freshness” checks
Application profiles

29. ANTI-REPLAY PROTECTIONS
Application profiles
Single-Use Tickets
Single-Use Tickets
Client-Hello Recording
“Freshness” checks
Separate API

30. ANTI-REPLAY PROTECTIONS (JUL-2018)
Single-Use Tickets
0-RTT without
protections
Single-Use
Tickets
Client-Hello
Recording
Application
Profile
0-RTT not available
Different API for
handling 0-RTT
Other protections
0-RTT only on “safe”
methods
0-RTT only on “safe”
methods, no params
BoringSSL
Partial
(HTTP Header)
n/a
n/a
n/a
n/a
n/a
n/a

31. ANATOMY OF AN ATTACK
• Vantage point in the network

32. ANATOMY OF AN ATTACK
• Browser and server with TLS 1.3 and 0-RTT enabled

33. ANATOMY OF AN ATTACK
• GET not being a “safe method” (a.k.a. RFC meets reality)

34. THE BROWSER BEHAVIOUR
• The browser decides when to send 0-RTT data,
which reduces the window for attacks

35. DEMO

36. IMPROVING OUR ATTACK
• Could it be possible to control when to send 0-RTT
data?

37. IMPROVING OUR ATTACK
• Could it be possible to control when to send 0-RTT
data?
YES!!!

38. CONTROLLING THE BROWSER

39. CONTROLLING THE BROWSER

40. CONTROLLING THE BROWSER

41. CONTROLLING THE BROWSER

42. DEMO

43. ANTI-REPLAY PROTECTIONS
Application profiles
Single-Use Tickets
Single-Use Tickets
Client-Hello Recording
“Freshness” checks
Separate API

44. IMPROVING OUR ATTACK (AGAIN)
• Imagine that somehow the TLS library and server
actually perfectly prevent any replay attack on 0-RTT.

45. IMPROVING OUR ATTACK (AGAIN)
• Could it be possible to do replay attacks?

46. IMPROVING OUR ATTACK (AGAIN)
• Could it be possible to do replay attacks?
YES!!!

47. UNIVERSAL REPLAY ATTACK

48. UNIVERSAL REPLAY ATTACK

49. UNIVERSAL REPLAY ATTACK

50. UNIVERSAL REPLAY ATTACK

51. UNIVERSAL REPLAY ATTACK

52. UNIVERSAL REPLAY ATTACK

53. UNIVERSAL REPLAY ATTACK

54. UNIVERSAL REPLAY ATTACK

55. DEMO

56. TOOL: HIGH-LEVEL DESCRIPTION
• Assumes a vantage point in the network
• Provides creation of templates for encrypted traffic.
• Supports the two attacks described on this presentation.
• Available at https://github.com/portcullislabs/tlsplayback

57. SIDE EFFECTS OF 0-RTT
• It is important to understand that 0-RTT creates a
dependency between the application and the
underlying TLS 1.3 protocol
• The application will need to be 0-RTT aware.
• Enabling 0-RTT could leave you application
vulnerable to replay attacks
• Ultimately, the last line of defence would be the
application itself.

58. MITIGATIONS
• Disable 0-RTT
• Ensure that your application does not allow
replays (e.g. strict CSRF). Ensure that REST services
are developed properly
• Create an strict application profile after careful
analysis

59. KEY TAKEAWAYS
• TLS 1.3 is awesome, but could lead to a
vulnerable application if 0-RTT is being used.
• Your application (not just webapps) needs to be
0-RTT-aware to prevent side effects
• You may need to change your application or
server/CDN configuration to protect against
replay attacks

60. Thanks!