This week, the Internet Engineering Task Force (IETF) formally approved TLS 1.3 draft 28 as a Proposed Standard, officially making it the latest revision of the Transport Layer Security (TLS) protocol. The approval comes after four years of revision by the TLS Working Group and leaves TLS 1.3 only a few verified implementations away from receiving Internet Standard designation.
TLS 1.3 contains several major differences from TLS 1.2 to improve both security and operability. New additions include:
- 0-RTT (Zero Round Trip Time Resumption). 0-RTT is a new negotiation mode designed to speed up resumed connections by allowing clients to send encrypted application data along with their session renegotiation message. This differs from previous TLS negotiation modes that require clients and servers to complete the entire handshake before sending encrypted data.
- Removal of all static RSA and Diffie-Hellman cipher suites. In TLS 1.3, only cipher suites that offer perfect forward secrecy (PFS) are allowed. Without PFS, an attacker that obtains an RSA private key or other pre-shared key off of a server could then decrypt all SSL/TLS traffic sent to and from that server. With PFS, every session uses a new unique key meaning a single compromised session doesn’t impact every other session.
- New session handshake process. TLS 1.3 overhauls the session handshake process, with changes such as deprecating the TLS 1.2 version negotiation field, encrypting all messages after the ServerHello, and even removing some messages entirely like ChangeCipherSpec.
You can find the rest of the major changes from TLS 1.2 on page 16 of the proposed standard document.
Of all the changes coming with TLS 1.3, the two most controversial ones are 0-RTT and the deprecation of the RSA key exchange. While 0-RTT significantly improves latency in many cases, it comes at the cost of security. Without going into the nitty-gritty details, 0-RTT messages are vulnerable to replay attacks, meaning an attacker capable of capturing your encrypted connection can re-send (replay) your 0-RTT data to the server, potentially triggering unexpected behavior. The good news is, most modern web applications are replay-resilient on their own to deal with normal network glitches. That said, 0-RTT’s inclusion means all applications and services that implement TLS 1.3 must be mindful of potential replay attacks.
The removal of the RSA key exchange and other non-PFS cipher suites has triggered concerns from many companies and organizations that rely on SSL/TLS decryption for security and data loss prevention. Members of the financial industry have noted that this change renders out-of-band decryption nearly impossible.
Potential privacy concerns aside, SSL/TLS decryption is vital for ensuring security in the modern work place. Malware authors are increasingly adopting encryption to hide their communication and second stage payloads from detection. Luckily, in-line proxies (like those in the WatchGuard Firebox appliances) will remain perfectly capable of decrypting TLS 1.3 traffic after implementing the new protocol standard. In-line proxies preform what is effectively a man-in-the-middle (MitM) attack against SSL/TLS sessions, a process that PFC-enabled cipher suites do not impact.
If you are a WatchGuard customer, we are in the process of testing TLS 1.3 internally while awaiting the final release OpenSSL v1.1.1, which will add support for the approved standard. Until the WatchGuard proxies officially support TLS 1.3, content inspection via decryption will still work, albeit by securely downgrading TLS 1.3 negotiations to TLS 1.2. –Marc Laliberte