TLS 1.3 is the latest version of the Transport Layer Security protocol. It aims to improve security and performance over previous versions. Key changes include removing support for older encryption standards, simplifying the handshake process to reduce latency, improving protections against downgrade attacks, and using ephemeral Diffie-Hellman key exchange for forward secrecy instead of long-lived RSA keys. While improving security, TLS 1.3 also faces challenges around compatibility with older systems and allowing passive network monitoring.

1. TLS 1.3
Kevin O’Brien
Washtenaw Linux Users Group

2. What is it?
● Transport Layer Security Protocol Version 1.3
● TLS replaced the earlier SSL
– SSL developed by Netscape in 1995
– Purpose was to create secure communications
between clients and web sites
– TLS can be seen as the next version of SSL
● Both SSL and TLS work by using certificates to
authenticate and encrypt (though TLS 1.3 modifies this)

3. Why TLS?
● Cryptography is an arms race
● SSL was starting to show vulnerabilities
– Downgrade attacks like POODLE
● SSL 2.0 deprecated in 2011
● SSL 3.0 deprecated in 2015
● TLS was an improvement

4. TLS 1.0
● TLS 1.0 defined in 1999
– Different enough that it could not interoperate with SSL
3.0
– Did allow for a downgrade to SSL 3.0. This is a
weakness, but when you introduce a new standard you
can’t get everyone on it right away
● PCI (Payment Card Industry) Council recommends moving
from TLS 1.0 to TLS 1.1 or higher by June 2018!

5. TLS 1.1
● Defined in April 2006
● Added protection against cipher-block chaining attacks

6. TLS 1.2
● Defined in August 2008
● MD5-SHA1 combination replaced by SHA-256
● TLS Extensions defined
● AES cipher suites added

7. TLS 1.3
● Proposed as new standard March 2018
● Removed support for older/vulnerable encryption
standards
– MD5
– SHA-224
● Removed support for weak and lesser-used Elliptical
Curves

8. Process
● 28 drafts over 4 years
● Final draft passed nearly unanimously (1 person voted “No
objections”)
● But there were some issues to work through

9. Middlebox problem
● A middlebox is any piece of hardware that inserts itself
between the browser and the remote server
● Example: A firewall sits in the middle and inspects all
packets to protect against malicious traffic
● This hardware will need upgrades to handle TLS 1.3
● So will browsers, but that is easy and is already done.

10. Maryland School District
● Montgomery County Public Schools updated to Chrome 56
● One-third of Chromebooks and “some” Windows PCs
suddenly could not get through the login screen any longer
● Google says this was because Symantec Blue Coat
security software implemented TLS 1.3 improperly
● Google temporarily paused rollout of TLS 1.3 in Chrome

11. Financial Services Roundtable
● Represents major banks
● Asked for a way to passively decrypt and monitor network
traffic
● They were somewhat late in asking for this
● It was not well received

12. “The bank industry is pushing the TLS
working group to create a decryption option
as part of the specification, and of course
the tech sector is saying ‘That’s not going to
happen,’ ” Janet Jones, a Microsoft senior
security program manager, told
CyberScoop. “Can you imagine us
supporting something that gave an API with
a decrypt button? We can’t do that.”

13. A great answer
● When the Financial Services Roundtable made their
request, this reply from Kenny Patterson was particularly
good

14. Hi Andrew,
My view concerning your request: no.
Rationale: We’re trying to build a more secure internet.
Meta-level comment:
You’re a bit late to the party. We’re metaphorically speaking at the stage of
emptying the ash trays and hunting for the not quite empty beer cans.
More exactly, we are at draft 15 and RSA key transport disappeared from the
spec about a dozen drafts ago. I know the banking industry is usually a bit slow
off the mark, but this takes the biscuit.
Cheers,
Kenny

15. The problem
● The banks proposal was seen as putting in a backdoor
● And there were better options
– Banks could install middleboxes to do what they
needed
– This would cost money, but not build in weakness to the
standard
● Backdoors will always be used by the bad guys

16. The solution
● Do a man-in-the-middle attack on the traffic
– Establish two connections
– One is with the browser initiating the connection
– The other is with remote server
– Then you can see all of the traffic
– Most users will never notice at this point

17. Latency
● TLS 1.3 improves the latency of connection requests
● It does this by simplifying the handshake
● Let’s look at a simplified (!) version of the TLS 1.2
handshake

18. TLS 1.2 Handshake
● The web browser (client) sends a message to the server and offers a list of
encryption protocols it can support.
● The server then replies with the protocol it intends to use and sends an
encryption key
● The client then uses that key to send back a random string, and they then
create two keys: a master key and a weaker session key
● The client then says which protocol it will use for the weaker session key.
Because this key is weaker, it is faster and less resource-intensive.
● The server acknowledges the session key and protocol
● They finally start exchanging information, which was the whole point.

19. Its even more complex
● I did that as a high-level look
● But even so it is complicated
● So let’s get a high-level look at the TLS 1.3 handshake

20. TLS 1.3 Handshake
● The client says hello, and says which protocols it intends
to use.
● The server says “Cool! Here’s my key”
● The client says “Awesome! Here’s the session key”

21. Faster!
● I think we can all agree that looks both simpler and faster,
with less negotiation all around

22. Security Improvements
● Many older encryption protocols no longer supported
● This includes removing support for certain elliptic curves
– I’m sure you recall the problem with NSA inserting a
weak curve into the NIST standard
– That is now out for TLS 1.3
● Hashing of session parameters
– Session parameters are what allows resumption

23. Downgrade Attacks
● There is also improved protection against downgrade
attacks
● This first appeared with SSL 3.0 and was motivation for
moving to TLS
● But earlier TLS (up to TLS 1.2) also had vulnerabilities
● TLS 1.3 makes this harder
– Removal of older protocols
– Detect and flag attempts to downgrade to TLS 1.2

24. New Handshake
● Older protocols used RSA to do two things
– Authenticate the seder
– Encrypt initial communications
● This has a weakness in that RSA keys are long-lived
● This opens up possibility of gaining the key and decrypting
older, stored messages

25. Forward Secrecy
● Of course, we have just described the problem that
Forward Secrecy is intended to mitigate
● And that means Ephemeral Diffie-Hellman is involved
● Every session is supposed to have a new Diffie-Hellman
key exchange (that is what makes it ephemeral)
● RSA is only used for authentication

26. 0-RTT Resumption
● A controversial inclusion is 0-RTT Resumption
● This allows the client and the server to “remember” the
connection and resume it
● Obviously introduces a weakness
● Clear case of the battle between security and ease-of-use

27. Deployment
● This will take time to roll out
● 0-RTT Resumption, for instance, requires changes that are
not compatible with older servers
● Ephemeral Diffie-Hellman poses problems for data centers

28. Data Centers
● Network Monitoring tools
– e.g Intrusion Detection Systems
– Currently do passive monitoring of connections
– Cannot work with ephemeral ciphersuites
● This is what the banks were objecting to
● But this can be addressed with a combination of new
hardware and network changes

29. Perfect Security?
● No such thing exists
● It is an arms race
● Every improvement in defense elicits new attacks
● You need to be aware of authentication certification
● And already some vulnerabilities in TLS 1.3 are coming to
light