SSL decryption and browsers behaviours

[Laurent_Dormond]

Hello,

We are planning to perform SSL Decryption for overall Web Traffic (we are a public organization of around 5000 users).

We have started several tests by implementing SSL Decryption Best practice like not decrypting "Financial Services" and "Health" categories.

However we are facing common issues with browsers that often states that connexion is not secured. This appears in various manners depending of the browser in use.

Here are some screenshots :

Internet Explorer

WebSite https://www.manor.ch/fr/

• SSL Decrypt disabled

• SSL Decrypt enabled

 

WebSite SSL https://www.migros.ch/fr.html

• SSL Decrypt disabled

• SSL Decrypt enabled

Firefox

WebSite https://www.manor.ch/fr/

• SSL Decrypt disabled

 

• SSL Decrypt enabled

WebSite SSL https://www.migros.ch/fr.html

• SSL Decrypt disabled

 

• SSL Decrypt enabled

 

As you can see, a user would think that the connexion is unsecure when SSL traffic is decrypted, thus we can't go ahead and deploy SSL decryption like this.

The certificate used for forward decryption has been signed by our internal CA, and thus is trusted by all the browsers.

How could we prevent this issue to happen ?

Regards,

Laurent

[bradk14]

without seeing the certificate details, I can point out that there is an inherent issue with SSL decryption in that what you are doing technically is performing a Man-in-the-Middle attack, replacing the site's real certificate with one being supplied by the firewall.

The first question is did you supply a certificate with resigning capabilities to the Palo Alto firewall for SSL decryption or are you using a self-signed certificate?

In either case, the clients need to be able to trust the self-signed cert or the cert's provider as a trusted root CA to avoid errors. What's happening is the PA is regenerating a new cert to present to the end user's browsers which claims to be from the website, but the browser needs to be able to trust the entire chain of the cert so that someone else without authority didn't create a false certificate on behalf of the server.

I'm not sure if that's making sense, but if there is a warning that there is a problem with the site's certificate, that is why. also there are varying levels of SSL certificates, the most trusted will change the address bar to green (depending on the browser). there isn't much you can do about that.

[TranceforLife]

Looks good on the labssl:

https://www.ssllabs.com/ssltest/analyze.html?d=migros.ch 

https://www.ssllabs.com/ssltest/analyze.html?d=www.manor.ch

As initially, l thought it is chain cert issue where IE and Chrome can deal with it and still show you a "green" padlock where Firefox will complain. Let's ask our friend @Gertjan-HFG. 

@bradk14 as OP said cert is trusted by internal users. 

[bradk14]

admittedly I didn't scroll all the way down that far to see the trusted CA, so I apologize.

in any case, again, it's hard to see what the cert errors being presented are just by the screenshots provided. there should always be a padlock for sure. the green bars/URL are because it's an EV cert, which PA is not generating, so that's why the green bar goes away. other icons indicate partial encryption, which is often because the page refers to non-https resources.

[OtakarKlier]

Hello,

In my testing I also saw invalid certificates until I gave the PAN a subordinate certificate so it can generate a cert on the fly. Once this was done, by my interal cert server, everything seem to be OK. IE and Chrome use the windows cert store so those should be OK. Firefox uses its own and that cert has to be imported into each firefox cert store.

Regards,

[Gertjan-HFG]

Looks like your missing the "generated PA root CA" on your workstation(s).

This is why you need that:

Ensuring the Proper Certificate Authority on the Firewall and Exporting the CA to Clients

Loading or generating a CA certificate on the Palo Alto Networks firewall is needed, because a Certificate Authority (CA) is required to decrypt traffic properly by generating SSL certificates on the fly. Either create a self-signed CA on the firewall or import a subordinate CA from your own PKI infrastructure. Select Forward Trust Certificate and Forward Untrust Certificate on one or more certificates to enable the firewall to decrypt traffic. Because SSL Certificate providers like Entrust, Verisign, Digicert, and GoDaddy do not sell CAs, they are not supported in SSL Decryption.

To Generate a Self-Signed Certificate:

• From the firewall GUI, go to Device > Certificates Management > Certificates. 
• Click Generate at the bottom of the screen. 
• For Certificate name (which can be anything) I chose ssl-decrypt.
• For Common Name, I entered the Firewall's Trusted Internal IP: 172.16.77.1
• Place a check box next to Certificate Authority to create a Certificate Authority and an SSL Certificate signed by the Firewall itself - x.x.x.x.

• If you want this certificate to be good for more than 1 year, please go into the Cryptographic settings, and choose, say, 2 years or 730 days. Now the certificate is good for 2 years.
• If you need to place any additional Certificate attributes, you can do so inside the window at the bottom.

• Click Generate, then notice that the Status shows as valid.
• Click ssl-decrypt, then place a check mark next to Forward Trust Certificate and Forward Untrust Certificate, then click OK. Now the certificate can be used for decryption.

If a self-signed CA is used, the public CA Certificate must be exported from the firewall, then installed as a Trusted Root CA on each machine’s browser to avoid Untrusted Certificate error messages inside your browser

[Brandon_Wertz]

--edit--

My comment presupposes that since you're a public company with a rather large user base you're using an internal CA. /edit

If your clients have the Root CA which is being used to generate your decryption certificate you should be fine as long as you've followed these steps:

https://live.paloaltonetworks.com/t5/Featured-Articles/How-to-Generate-a-CSR-Certificate-Signing-Req...

Be sure to pay close attention to this step:

Import the Signed Certificate

1. Note the name, including capitalization, of the certificate to import. (This must match the CSR request from above.)

On a recent CSR endeavors I did the cert that was given back to me after it was signed was renamed and wasn't working properly.  Once I renamed the cert to the originally generated name the cert chained together.

Your cert chain should look something like this more than likely

[Laurent_Dormond]

Hello,

Many thanks for your help so far.

First of all, as I said in my initial post, we are not using a self-signed certificate :

"The certificate used for forward decryption has been signed by our internal CA, and thus is trusted by all the browsers."

Here is a screenshot of the certificate for a website that is not working properly :

Sorry it's in french...

LSNRCA01 is ou internal CA

I have generated the CSR with "Certificate Authority" checkbox enabled.

Then, for several websites, like www.google.com it's working fine (no issue with the certificate when ssl decryption is in use) :

Regards,

Laurent

[Gertjan-HFG]

OK, you don't get a green bar, because with PA decryption can not send a EV certificate.

Is you use firefox you have to import the internal CA because firefox uses its own certificate store

[bbilut]

If your computers are in a Windows domain you can easily use Group Policy to push your cert out too all your machines and put it in the trusted root. Like some other have mentioned this will take care of Chrome, IE, & Edge, but not Firefox as they have their own cert store and don't use the one built into Windows.

[Laurent_Dormond]

All of the required certificates are in the appropriate certificate store.

Without talking abouot Firefox, my main concern is dealing with IE since this is our corporate browser.

I still can't deploy SSL decryption, because the visual aspect of the browser bar is significaly different when the SSL decryption is enabled. As you can see from my first post above, with IE it's likely there is no secured session established despite the fact that SSL decyption is enabled...