Update 08/12/2017:
It seems that corporate interest and concern about frauds drives over privacy. There is IETF draft which explains methods how MITM can be done also in future:
https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01?lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3BXwPTluc4SkCHhmc0hYE3Vg%3D%3D (Data Center use of Static Diffie-Hellman in TLS 1.3 draft-green-tls-static-dh-in-tls13-01)
In this post I will be focused in TLS version 1.3 and specially those parts what I think that will change the mature of the NGFW as we know it.
TLS as you maybe know it’s cornerstone of the encryption in modern Internet world. If you take browser session to your bank it is TLS protected and probably it is protected by TLS version 1.2. So why we need new TLS version? Answer can be that we need more privacy and faster response time, but the obverse for this is that it is more difficult to see where the client is going and what is the data inside encrypted HTTPS session.
Let’s first look what we can see in TLS 1.2 protected traffic without TLS decryption. TLS session start with client hello and after this comes server hello and client key exchange etc (picture 1).
Picture 1. TLS 1.2 RSA handshake (2 round).
After handshake is finished, then application data is encrypted. If we look this traffic in the Wireshark we can see that even we don’t decrypt it there is lot’s of metadata information what can be used in NGFW. NGFW can do filter based on certificate information what server sends to client. If you take www-session to youtube.com, server certificate tells quite much.
There is fields what we can see like SubjectAltName, issuer, country, state, validity etc information (Picture 2).
Picture 3. Server hello.
If we tie up this information about that information what our client tells we can be quite sure where the client is going and if it’s safe site based eg. reputation information.
When client sends hello message, it adds field called “Server Name Indication” SNI in the request (picture 3).
Picture 3. SNI field in client hello.
Now we have handled basic filtering options based on that information what certificate and client can tell in TLS1.2 world.
If your NGFW is capable to make SSL-interception (like Cisco NGFW and some others), in other words doing man-in-the-middle function. Then you can decrypt HTTPS traffic and do some more filtering (and eg. malware scanning and sandbox) based on that data what NGFW can now see in plain text. Basic function SSL interception is that NGFW signs certificates for it’s own corporate trusted root certificate (picture 4).
Picture 4. Basic SSL interception (2 round).
Because TLS 1.2 can use static RSA keys in the encrypt/decrypt session it’s quite easy and “light” to do SSL-interception, you can try it yourself using tools like Burp Suite. There is also possibility to use Elliptic Curve instead of RSA, key exchange is quite similar in ECDSA. Main difference is that after server sends certificate it also sends ServerKeyExchange message. Decrypting Elliptical Curve Digital Signature Algorithm (ECDSA) protected traffic will use more processing power that RSA based, because proxy process needs to calculate more keys.
All the methods what I have described above can be used to see inside SSL-protected traffic or can be used filtering traffic based on certificate information. SSL-interception feature has also one drawback, browsers can detect that eg. https://www.google.com is not signed in valid root CA and can gives warning.
So how the TLS version 1.3 change the game field?
First the good news, there is no RSA anymore. Then the bad news visibility to the traffic is terrible if we think security and filtering.
TLS 1.3 handshake is totally different (picture 5). There is only 2 phases. First Client sends information and server responds.
Picture 5. TLS 1.3 handshake.
After this all data is encrypted. If we first look client hello, we can see that there is only SNI field (picture 6), just like TLS version 1.2 was.
Picture 6. Client hello.
SNI based filter is working for the standard user, but it can be manipulate for certain tricks. Now see what’s server hello can tell us (picture 7).
Picture 7. Server hello.
Nothing, in TLS version 1.3 we cannot see anything and this is the reason why NGFW will change. We cannot anymore use metadata for server certificates. In transparent proxy/firewall mode we cannot see anything what is inside SSL session. Also decrypting TLS 1.3 is verry difficult, because in every new session will generate new keys (picture 8) so that SSL-interception should be done in every session. There is also some other features which make interception even more difficult.
Picture 8. TLS1.3 sessions.
If the hacker breaks one session there is no effect for other sessions, because those are using different keys.
So what we can do if script kiddie can manipulate SNI field and we cannot use SSL-interception? Is the NGFW URL-filtering story ended? Well we can ease our pain to use good old proxy pac feature (and maybe opendns plus AMP4Endpoints also). Proxy pac implementations has one good feature. Browser send (CONNECT request) target where it try to go in plain text and we can use this feature in URL-filtering (picture 9).
Picture 9. HTTP connect request and TLS 1.3.
This means that company firewall needs to block http(s) access from other sources than proxy address.
There is also effect for application intelligence, if browser based applications start using TLS 1.3 we lost view for data.
So what I think is that vendors will implement some lightweight proxy function in their devices, so they can see more information where client is going in TLS 1.3 world. They will also use more and more reputation based solution where site is pre-checked before client is allowed to make connections. This is only my guesses, but let’s see.