04-09-2018 03:45 AM
We've been using SSL decryption inbound for a while. In order to decrypt traffic based on DHE and ECDHE ciphers, we moved to PAN-OS 8.0. On 7.1.10, traffic with those ciphers were not decrypted but passed through. Now, on 8.0.6, we see drops.
The decryption profile sets TLSv1.0 only as protocol, but we allow other protocol versions and ciphers (block unchecked for unsupported versions and chiper suites).
When the decryption policy is enabled, requests from Firefox v.59 (Windows, Linux and Android) get an SSL_ERROR_ILLEGAL_PARAMETER_ERROR.
I couldn't find info from Paloalto describing those errors. They say when decryption is not supported, session is not decrypted and passed through the firewall, as metioned here:
https://live.paloaltonetworks.com/t5/PSIRT-Articles/Safely-inspecting-SSL-transactions/ta-p/148517
Briefing, decryption policy enabled: we get errors. Decryption policy disabled: everything works fine.
Am I confused or this is the expected behaviour?
04-09-2018 02:03 PM
Can you post how your decryption profile is actually configured. Part of your question really doesn't work together; you are only allowing TLSv1.0, but you also say that you are allowing other protocols?
04-10-2018 12:40 AM
Well. This is the profile. I only want to decrypt TLSv1.0. Other traffic is supposed to be allowed without being decrypted, or I may have misunderstood how inbound inspection works.
When the issue happens, the client try to negotiate TLSv1.2 and something goes wrong.
This is captured on the FW, at firewall stage:
And this is captured from the clientside:
After opening a case, a workaround has been supplied: "Enabling TLSv1.2 on the profile, it works properly". Anyway, that's not the point. Because traffic that can not be decrypted should be allowed as SSL, isn't it?
If I don't want to decrypt nor block sessions based on TLSv1.1 or TLSv1.2, why are they being blocked?
04-10-2018 01:39 AM - edited 04-10-2018 01:00 PM
If connections from specific clients are blocked, are these connections blocked permanently or does it work when you reload the website?
04-10-2018 01:18 PM
In my experiance if the traffic can't be encrypted you'll usually run into issues, the firewall doesn't just allow this traffic to pass. Since you were setting a minimum of TLSv1.0 and a max of TLSv1.0 you were actually setting it so that the maximum protocol version that could be used was TLSv1.0.
I've never actually setup a decryption profile to attempt to focus on one protocol version, so I'm not positive how you would do that. I believe that you would have to actually setup a decryption policy that had a decryption profile with min TLSv1.1 and max set to Max with a 'no-decrypt' action above your existing policy. I'm not 100% sure that even that would function however, because I don't know when the firewall actually checks that the traffic matches the decryption profile.
04-11-2018 12:38 AM
@BPry wrote:In my experiance if the traffic can't be encrypted you'll usually run into issues...
That sounds interesting.
This concrete scenario has been some kind of coincidence, but the point is that we had deployed SSL inbound inspection for many web apps and we have disabled every deciption policy until we clarify the FW behaviour.
I've tried the no-decrypt-policy-based workaround you have proposed. It seems to work properly but it is still a workaround.
A member of the Paloalto support team has admitted that it is not the expected behavior. So, I hope they are going to study the case.
Thanks for your help!
04-11-2018 07:35 AM
Back with PAN-OS 7.1 when it was working, do you know what version chrome was on? But as already mentionned by @BPry, when the firewall tries to but cannot decrypt the connection this leads to problems in most cases. In this situation of you I would expect that the first attempt fails and then the connection is placed in the exclude cache as you do not block "unsupported" protocol versions.
But depending on the TLS Handshake the firewall may not be able to do that as it assumes the decryption works but it does not (TLS Handshake compatibility). When TLS1.2 should be used but the handshake is done in a way that it works also for servers with TLS1.0 (as it should according to the RFC) there might the location of this (possible) bug. So the firewall assumes it is doing everything correctly and from client perspective it looks like a protocol downgrade attack. I know a lot of speculation 😛 So I am interested what TAC says on this. Did you try to connect from a system/browser where you manually force everything to TLS1.2 only?
And now to something (almost) completely different: if you decide to do inbound decryption, shouldn't it be the opposite way? Decrypt TLS1.1 and 1.2 and block TLS1.0 with the decryption profile? (I am sure you have your reasons, so I am asking only because of personal interest)
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!
