so TLS 1.3 got IETF branded

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

so TLS 1.3 got IETF branded

L1 Bithead

hey there,

 

since tls 1.3 is now a ietf standard, is there any use running ssl-decryption in the close future?

as far i understand 1.3 documents, it "looks like" 1.2 for the firewall, so there's no way to just block 1.3 and force both parties to downgrade to 1.2, or i'm wrong?

 

any news/tech docs from pan about the 1.3 "issue"?

 

so long

o/

6 REPLIES 6

L7 Applicator

This will be interesting ... I am waiting already quite a while for an answer ...

Not sure where I read that, but the only chance seems to be an explicit proxy or the complete visibiluty for encrypted traffic is gone.

TLS1.3 in combination with DoH and also the DNS sinkhole feature is gone...

Cyber Elite
Cyber Elite

@ADK999,

You'll need to block TLS 1.3 on the client itself to force it to attempt to failback; but you're 100% right, the standard really isn't able to be decrypted as far as I'm aware. 

The standard will be interesting, as it essentially makes any sort of decrytion from the firewall as we know it impracticle. I wouldn't be suprised to see a move back to full fleged proxy servers or agent based firewalls directly on a end-users computer. I think at this point though we're still waiting on a good solution. 

I haven't read up on this but I'm assuming Inbound Decryption could eventually work if they implemented TLS 1.3 on PAN-OS?

 

Since you generally own the cert and servers with Inbound then you could always make them use TLS 1.2 but if your server team wanted to implement 1.3 wouldn't the firewall still be able to decrypt with the cert installed?

Yes, inbound decryption will work - as soon as PAN-OS supports TLS1.3.

Until then - as the firewall does not know about TLS 1.3 - it only offers TLS1.2 to the clients as highest version. If the server in this case obly support TLS1.3, the inbound decryption will fail.


@jsalmans wrote:

 

Since you generally own the cert and servers with Inbound then you could always make them use TLS 1.2 but if your server team wanted to implement 1.3 wouldn't the firewall still be able to decrypt with the cert installed?


indeed, if the firewall works as endpoint (tunnel must be terminated at the firewall).

as far i understand 1.3: passive decrypting (virtual wire decryption for an example) with the private key won't work anymore since all connections are PFS crypted.

 

but my problem is more about the outbound connections. how shall we prevent business senstive data leaks or detect malicious streams if anything is just "ssl"?

the good side from 1.3, it prevents nsa, gchq and mossad from spying on us, (let's assume the is no willingly coded backdoor in pan systems) as long the is no direct access to client or server (pfs debug keys), but this also is a major issue for network based security.

@ADK999 @jsalmans @BPry

Today I did some tests with TLS decryption and TLS1.3.

Conclusion: Paloalto is able to "downgrade" a possible TLS1.3 connection to TLS1.2 and is also able to block connections to TLS1.3 only websites.

 

This works for example for the website "www.cloudflare.com". This website offers TLS1.3 but also TLS1.2. Because of the fact, that the client does not know if the server offers TLS1.3 it sends some information that it supports TLS1.3 in the "supported_version" TLS extension towards the server. This extension will be stripped by the firewall (or not offered at all respectively) in the TLS client hello that the firewall sends to the webserver.

 

As @ADK999 wrote, yes the TLS1.3 handshake "looks like" a TLS1.2 handshake - but not completely. So there are two details, where it is possible for the firewall to block TLS1.3 connections:

  • TLS version sent by the server in the TLS server hello
  • Cipher suites offered by a TLS1.3 only server

This is how the TLS Client Hello looks like from a Firefox 61 which I manually forced to TLS 1.3 only:

tls-handshake.png

Green circle = TLS Handshake make TLS1.2 compatible

Red circles = Things on which paloalto is able to block the connection

 

So with a decryption profile that blocks unsupported versions and/or unsupported cipher suites you are able to block the access to TLS1.3 only webservers. With PAN-OS 8.1.3 you actually don't even need a decryption profile attached because the decryption fails completely without the firewall adding the website to the exclude cache.

 

So for now there is no need to block TLS1.3 on the client because the firewall is able to force a connection with TLS1.2. As I mentionned it is also possible to block connections to TLS1.3 only servers and this makes it possible to decide website by website which you will allow and manually add to an exclusion list and which ones will no longer be available for your users.

 

With these prerequisites it is possible to maintain the current visibility offered by paloalto firewalls - mainly because I don't excpect many websites moving to TLS1.3 only. Till then paloalto (and all other firewall/TLS proxy vendors) need to come up with a solution and this solution so far seems to be going back from a transparent to an explicit proxy.

  • 6440 Views
  • 6 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!