Draft 28 of TLS1.3 has been approved by the IETF which means very shortly we’ll see web browsers and servers start upgrading to support this new protocol – in fact many have been testing using the draft specs for a while.
TLS 1.3 is a big change to web security HTTPS, and you may have heard that it make it harder for some security devices to examine what’s going on.
My background is in web security so let’s look what this might mean for web security, filtering and monitoring applications.
As with all existing SSL and TLS protocols their purpose is to encrypt the payload that’s communicated between the client and web server protecting privacy and integrity of the data within. This has always restricted what a 3rd party can see on the wire. There is however some useful data which is needed to establish a connection and therefore cannot be encrypted, that will remain the case with TLS 1.3
What’s visible as standard?
- IP Layer; Source / Destination IP addresses
- Server Name Indication (SNI): Domain Name
- Certificate Data: Domain Name (common name), Certificate Authority
(Other data is visible during the handshake but not so useful from monitor purposes)
So typically, on even simple network monitoring devices you can log, timestamped entries of who visited specific domains and roughly how much data or how long a session lasted.
However full URI and web content is protected.
Filtering / WAF Applications
At a basic level the same as above applies, and you can filter but you will be limited to the sledgehammer approach of filtering entire domains or IP addresses.
In some cases, this is practical, for example when combined with current threat intelligence you may have a list of IPs that are acting as malware C&C servers, or you might be happy blocking a whole domain such as playboy.com. Preventing access to a particular unsuitable video on youtube.com this way would not work well as you’d likely have to block entire access to YouTube.
This hasn’t really changed from TLS 1.2 however so there are already methods to decrypt the data described below.
HTTPS interception / Man-in-the-Middle
To log more detail or filter HTTPS more accurately you need to see inside the encrypted packets. This has been possible typically via two methods
Encrypted data could be later decrypted by a device if it has access to the certificate private key, allowing the device to decrypt and examine the data. This method is more common with WAF and IDS/IPS type devices on perimeter of data centres.
TLS 1.3 will drop support for static RSA key exchange, effectively forcing a Diffie Hellman based exchange with “Perfect Forward Secrecy”. This means just having the server private key is not enough to decrypt the transmissions, you also need the DH generated key for each session.
Static RSA was already not recommended in TLS 1.2 however remained popular with many servers to allow their data centre security devices to inspect traffic before hitting the server.
More common on web filtering platforms, where a private CA is generated and trusted by devices within an organisation. The intercepting device configured as a proxy can then accept and establish the client connection locally and establish a second TLS connection to the server. Both sides are now encrypted but the data on the device is unencrypted and can be examined or filtered.
This will likely still work with TLS 1.3 as long as all parties support the protocol. Existing downsides of this method such as administrative overhead of managing your own CA and certificate pinning will still remain.
Existing Device Compatibility
Is my internet going to break tomorrow?!
This was a huge concern with the team designing TLS 1.3, after much debate it was decided to leave a Middle-box compatibility mode enabled by default. This will allow TLS 1.3 to appear the same as TLS 1.2 to middle boxes or proxies while still gaining the benefits of TLS 1.3.
What should I should check for compatibility?
Obviously if your vendor explicitly supports TLS 1.3 then great, however these things tend to take time to deploy and some vendors are much slower than the wider browser / web server community.
I’d recommend asking if you can’t find an answer, that way it shows there’s interest in supporting the functionality too.
Next best thing would be support TLS1.2. It was released a decade ago, but you might be surprised as some vendors still don’t fully support it and often rely on downgrading to previous versions or TLS or even SSL! (You should really consider moving another supplier if they don’t support this!)
If using passive type of interception to protect your servers, check with the vendor as you’re likely to lose visibility and some functionality at least. I expect short term they will recommend to remain using static RSA on TLS 1.2 but long term will need to consider an alternative solution to support TLS 1.3.
If using an active interception or proxy again to check with the vendor if TLS 1.3 is natively supported. In the short term it’s likely servers and clients will continue to support TLS 1.2. These devices should be able to safely downgrade the connection to TLS 1.2 if needed since they negotiate two separate TLS connections between client and server.
Important Note: If a device attempts to passively intercept and downgrade a TLS 1.3 connection directly between the server and client this will cause problems! As an adversary could exploit this for malicious purposes by switching to a weaker protocol and cipher, a TLS 1.3 enabled server will hide a message indicating it was downgraded and if a TLS 1.3 compatible client sees this it will reject the connection.
Sources and Links
IETF TLS 1.3 Draft 28 https://tools.ietf.org/html/draft-ietf-tls-tls13-28
Great presentation from Cloudflare explaining TLS 1.3 https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/