This post is the second part of my series around the impact of encrypted protocols on network security. You can find the first article about HTTP/2 here:
http://blogs.cisco.com/security/the-impact-on-network-security-through-encrypted-protocols-http2

Now let us focus on the new and upcoming specification of TLS 1.3. It is important to understand what advantages TLS 1.3 brings to us, but also what is the impact on certain parts of our network security: firewalls and transparent proxy systems.

Lets start with a quick comparison of the functionalities and improvements of TLS 1.3.

TLS 1.3 is currently , at the time of writing this article, in draft stage:
https://tools.ietf.org/html/draft-ietf-tls-tls13-18

Why a new version of TLS? First of all , because of all those  attacks (with sometimes "funny" names) that have been discovered in the last years for the TLS protocol:

• POODLE

  • SSLv3 Problems with Padding, turn of SSLv3

• BEAST

  • Known issues in CBC mode, use TLS 1.1/1.2 with non-CBC mode ciphers (GCM)

• CRIME/BREACH

  • Compression Data Leak, disable compression in TLS (CRIME), HTTP Compression still there

• LUCKY13

  • Problem with Padding still exists with CBC Ciphers, use TLS 1.2 with AEAD (GCM)

• FREAK

  • Downgrade to RSA_EXPORT, disable EXPORT CIPHERS, use TLS 1.2

• LOGJAM

  • Force client to downgrade to DHE_EXPORT Grade ciphers, disable DHE_EXPORT Ciphers, use TLS 1.2

This is not a complete list but just some examples. The result is that you have today some TLS versions that are partially broken, come ciphers that are broken and certain behaviors that you should be avoided at all costs.

Secondly, TLS 1.3 will reduce the number of roundtrips required for the handshake. TCP plus TLS has quite a communication overhead, with a lot of messages floating back and forth. TLS 1.3 will reduce the overhead and will increase the efficacy of the protocol.

Here are the most important changes:

• Remove of static RSA authentication mode
  • Using DHE / ECDHE instead for PFS
• Reducing overhead by using a 1-RTT (Round-Trip ) handshake
  • Fallback to "legacy" handshake if the client cannot handle it
  • 0-RTT Session resumption -> using tickets + PSK
• Remove non-AEAD Ciphers (like CBC), compression, RC4, MD5, SHA224
  • Many of the old and actually broken ciphers are gone.
• Encrypting more values in the handshake
  • Server Certificate with its extensions such as CN & SAN

So TLS 1.3 is more efficient and provides improved security. But it also has impact on network devices. Our main focus shoud be on the last point I mentioned: Encryption of handshake values such as the server certificate with all of its extensions.

Why is that important?

Imagine you have a networking device (transparent proxy, firewall,...) and it tries to decrypt certain traffic for the clients. When it sees the very first packet , the TLS client hello, it needs to figure out, where the heck the client wants to go. For example, is it a banking website, so you do not decrypt? Or is it another website that you want to decrypt?

The problem is that in the TLS Client hello, you only have the destination IP and the destination port (usually TCP/443 in case of https) as indicators where the clients wants to connect. The majority of other information is not useful to detect the destination host. Many implementations of decrypting gateways now actually either pass the TLS client hello to the destination server or they send their own TLS client hello. The destination server then sends back a TLS server hello and its certificates. Now, the networking device looks at the certificate and reads the CN ( common name) field of it. This is how the device that does do decryption is usually discovering the destination host.

Example 1:

Now look at the certificate from "youtube.com":

Figure 1: TLS Certificate Example -youtube.com

Brilliant! It says "*.google.com".  If you want to allow search engines but block video portals, good luck....

Example 2:

If a provider is hosting several websites behind one IP, he needs to know which server certificate he should send back as a response to the TLS client hello. There is a feature helping here and it is called : SNI (Server Name Indication)

Figure 2: PCAP of TLS Client hello with SNI

Now back to TLS 1.3:

In TLS 1.3, the TLS client hello is already sending a Diffie-Hellman key share. The server is sending then his own key share and has already encrypted the values like the certificate with all of its extensions.

Figure 3: TLS 1.3 partial handshake

As you can see in Figure 3, our intermediate gateway can no longer check the CN field of the certificate but relies only on the SNI string.

This string is still readable and is not encrypted or signed or in any way protected...Can the SNI string be spoofed?

Yes, it can. There is a proof-of-concept that tried exactly that:

https://hal.inria.fr/hal-01202712

And this spoofing of SNI is causing a lot of confusion for the transparent proxies, firewalls and other devices that need to decide whether to decrypt or not.

You might have noticed that I have been talking about transparent proxies in my examples. What about explicit proxies? Well, in a explicit deployment (such as with proxy settings or with PAC files), the client always make a HTTP CONNECT request towards the explicit proxy server. After the HTTP CONNECT request, the TLS Client Hello is sent. Explicit proxies can read the hostname directly from the HTTP CONNECT request. They do not rely as much on SNI as transparent devices.

I am delivering a talk about exactly this on CiscoLive! in Berlin in two weeks, so if you are around, happy to welcome you to my breakout:
BRKSEC-3006 TLS decryption using the WSA

In summary, TLS 1.3 will be a more secure and efficient protocol, but its time to re-think the HTTPS decryption strategy. It might be that Web decryption is no longer the only thing we need to apply but add adjacent strategies.

Further helpful informations around TLS 1.3:
https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/

https://www.imperialviolet.org/2015/05/16/aeads.html