SSL interception on Palo Alto Networks (PAN) devices can be super powerful and is often considered a must if you’re not content with just seeing “SSL” come up as the application. Offloading this SSL traffic means we can no longer scan it for things like viruses, spyware, or even file content we might not be content with letting out (or into) our network (double “content” intended, now known as 2CON).

As you are probably aware, SSL interception requires a Signing CA to be imported (or generated) to be used as a Forward-Trust certificate on the PAN device. Do NOT use the same certificate as the Forward-Untrust as you will then be issuing valid certificates to clients for sites that have Untrusted-Issuers themselves. Once this is ready to go, you will need to import it into every client who will be intercepted. Without this CA on workstations, users will be constantly prompted with every HTTPS site they visit, and the certs issued are from an unknown issuer. Fair enough.

Googles Chrome is a little interesting in this regard. More than just “Best Practice” you really do not want your users to get used to adding exceptions for sites. Chrome takes it a step further, basically stopping you entirely from accessing Google Apps and sites if Chrome sees a non-trusted certificate. There is no option for adding an exception and continuing. You just… Stop.

 

Thankfully, doing the right thing and importing the CA into your OS fixes this (Chrome uses the same certificate store as Windows/IE/Edge). An even better approach, if your clients are all on the domain, is to use a CA that has been issued by the domains CA. That way, thanks to the chain of trust, they already trust the issuer. Happy days (unless you’re a firefox user as it uses a different cert store).

You would be forgiven for thinking at this point that everything is honky-dory. The issue is this semi-awesome thing called QUIC. You can read the wiki article about it here, but essentially, some of the folks at google have been working on an experimental way to improve perceived perception of the performance of HTTPS sites. Perceived perception… Anyway, QUIC uses multiplexed UDP connections to handle equivalent SSL/TLS negotiations. PAN detects this as an application, and you can block it if you like. The issue we have here, is our SSL interception won’t be triggered. We will see the QUIC protocol taking effect, then SSL traffic. We can’t generate a cert for the site in question as we don’t see the original cert being transferred. What this leads to is no interception of any site that has QUIC enabled, assuming clients are using Chrome, and its in its default state. The good news is most servers/sites aren’t very quick on their uptake of QUIC (2QUIC). As of today, (May 12,2016) www.google.com for example does NOT utilise QUIC, but YouTube does! This affects Chrome on Windows, Mac, Linux, Chrome OS, and Android. I have long defected from iOS and the Apple Eco-System, so you would need to test Chrome on an iOS device to confirm if it behaves in the same way.

More good news, it’s not too difficult to fix. As an end-user, all you would need to do is type chrome://flags in your browser, then scroll down to the “Experimental QUIC protocol” field, and toggle it to disabled:

 

Once complete, you will need to restart Chrome and test. A visit to YouTube will confirm that SSL interception is now working! I would recommend watching a video while confirming that the certificate being displayed is issued by your CA. You will need to open it in a new window of course.

The PAN device might actually still detect the YouTube app regardless of SSL interception status, after you have visited YouTube for extended periods of time, I would pop over to gmail, login and confirm the cert is issued by you, and test by sending an email with some explicit text that should be blocked by a custom file blocking profile on a test policy (You would need to create this ahead of time). Something like “The new Macbook is great” would be a great string to block.

You can push these settings through Group Policy for your domain users, although I have found it’s a little hit and miss and may be dependent on which version of Chrome a user has. Also, I’ve heard that even with the change in place, if you go to Chrome://flags it may incorrectly still display enabled, even though under the hood it is indeed disabled. The proper test is to go to a site you know is QUIC enabled, like gmail, and confirm that SSL interception is working on that client.

More information can be found on Palo Alto Networks LIVE site here.

Written by Ronen Meshel
You can read more about Ronen on his website: ronen.it/