I host a few TLS encrypted websites at home, and as part of my recent lab testing, I noticed that Palo Alto supports PFS based decryption. I’ve had many open source tools previously that noted I was constantly under a barrage of attacks on my web server. Decrypting this traffic and seeing what is happening under the secrecy of encrypted traffic would come a long way in deterring and even preventing intrusions into my web server.

As I implemented the policy, I noted handshake failures during the negotiation with the error “decrypt-error” and “decrypt-unsupport-param” which wasn’t very helpful. The client browser would give the error (this is in Chrome) “ERR_SSL_PROTOCOL_ERROR.” I captured a tcpdump on the firewall and examined the handshake which gave me little evidence at first as to what was going on. The only piece of evidence it gave me was the cipher it selected, and the error “Alert (Level: Fatal, Description: Handshake Failure).” I had a hunch that something was wrong with the PFS decryption so I modified my web server configuration to remove the PFS options. Sure enough, that allowed the firewall to decrypt the traffic, but I was having sporadic issues accessing the sites.

Just to make sure I was sane, I double checked the Palo Alto Perfect Forward Secrecy (PFS) for Inbound SSL Sessions documentation just to make sure I had everything set properly. I was running 9.0.3 code on the firewall. I checked my decryption profile and that the DHE and ECDHE key exchange algorithms were selected.

I then ran through the basic Configure SSL Inbound Inspection documentation. I was running a layer 3 firewall and the certificate was imported properly with the intermediate CA attached to the certificate chain. I checked my decryption rules, but I had it misconfigured here. My traffic is hidden behind a single public IP address. I’m not given more than the one by my internet service provider. As part of this, I perform port translation inbound. I found the following article, which states that I should create a separate URL category for each website I host on this server and use that in my decryption rule. I will say, it was a little ambiguous as to whether I should use the IP address in the destination or not as they have a note stating:

“if you are hosting multiple servers on the same machine 1.2.3.4 (same IP), then make sure that the SSL decryption policies are not configured with IP address as match condition.”

But the examples they have below still have the destination IP address listed. I tried it both ways just to test with no effect. I will say, I had the same error they listed in the article and it went away after putting the custom URL category for each website in the decryption profile, which resolved my issue of the sites being sporadically unavailable.

Now I just had one more topic to handle, which was being able to reenable PFS for my websites. I decided to validate if that cipher the server selected was supported by the firewall. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 was the method selected, and according to the PAN-OS 8.1 Decryption Cipher Suites documentation, it was supported. I double checked my imported certificate with the certificate and CA bundle I was given from GoDaddy. The CA bundle was different than what I had added to the certificate originally. So I replaced that certificate and committed my change. This time I got a different error message from the client browser. It was a ERR_CONNECTION_CLOSED with the same error messages in the traffic log. I tried removing the Decryption profile from the rule with the same effect.

After reviewing the output of “show counter global filter delta yes” I found the following entries which did not look promising:

name                                         value     rate severity  category  aspect    description
 proxy_reverse_unsupported_protocol           38        4    warn      proxy     pktproc   The number of sessions failed for reverse proxy because of ssl protocol
 proxy_decrypt_unsupport_param_overall        38        4    info      proxy     pktproc   Overall number of decrypted packet unsupport param failure

Searching for those specific errors, I came across this KB article from Palo Alto Networks entitled How to Identify Root Cause for SSL Decryption Failure Issues. It appears that even though the Palo Alto supported ciphers for 9.0 list the specific cipher I was using, it apparently does not fully support it. In this packet capture, you can see where the firewall sends a TLS fatal alert to both the client and the server to terminate the session. So if you are looking to only use modern cryptographic algorithms, it appears the Palo doesn’t quite support this yet.