Palo Alto and Bluecoat SSL Appliances and your PKI Security

Over the last year a common question has surfaced repeatedly as customers look to adopt SSL Packet inspection services for outgoing connections. These appliances are designed to allow monitoring and management of data contained inside of normally protected SSL sessions being initiated inside the organization. In order for these appliances to work, they have to be able to establish essentially a Man-In-The-Middle attack against corporate traffic to be able to inspect and manage that traffic.

Except in this case, the “Attacker” is a corporate security appliance, but the concepts are the same. To accomplish this MITM attack, these appliances (Palo Alto and Bluecoat are the most common) take advantage of a weakness in SSL/TLS. When a web browser negotiates an SSL/TLS session with a website, it doesn’t know WHICH CA should/did issue the certificate for the website – it only cares that it comes from a trust CA. Whether that is a commercial provider like Comodo, Globalsign or your internal PKI, it all doesn’t matter to the SSL/TLS negotiation.

So these appliances act as a subordinate CA of your PKI and use that certificate to create website certificates on the fly. Open a browser and go to www.contosobank.com, and the traffic is directed to the appliance and it creates a certificate for www.contosobank.com which subsequently chains to your PKI and is trusted. On the back-end, the appliance sets up a real connection to contosobank.com and sends your traffic on once it has been inspected/managed. So you are none the wiser.

So why do I bring this up? One of the issues with these appliances is that in order for them to function, they have to be a trusted CA. This can either take place as a self-signed certificate the appliance creates which you then need to distribute. This is a bad idea as it can’t be managed, revoked or monitored. It also doesn’t work well for machines you can push a Group Policy to as you would need to touch every device to trust this self-signed certificate. Another method is to enroll the appliance for a Subordinate CA certificate from your PKI.

The security of these Subordinate CA certificates should begin to tickle the hair on the back of your neck. These certificates (and keys) will be trusted by your enterprise, clients and servers like any other CA you have deployed. So what if you are using Hardware Security Modules (Thales/SafeNet Gemalto) to protect your CA keys? The act of enrolling and issuing Subordinate CA certificates to these devices could potentially nullify all of your HSMs and security controls you have put into place. If these appliances are the weakest link in your PKI, then you need to be sure you are adequately taking precautions to safeguard these devices to the same security level as your CA and the rest of the signing PKI infrastructure (OCSP, NDES, etc…)

So what can you do? Here are a few options to consider before blindly enrolling and deploying these devices:

• Ensure the appliances can use HSMs to create and manage their keys. Bluecoat and Palo Alto both support HSMs by Thales and SafeNet. But you must make sure there is network connectivity to your HSMs and ensure the creation and enrollment of those keys are indeed occurring on the HSM. You will have no visibility of the protection of these keys when you view a certificate request sent to you. Be sure you are part of the creation process to ensure those keys are protected.
• Ensure the appliances can use HSMs to create and manage their keys. Bluecoat and Palo Alto both support HSMs by Thales and SafeNet. But you must make sure there is network connectivity to your HSMs and ensure the creation and enrollment of those keys are indeed occurring on the HSM. You will have no visibility of the protection of these keys when you view a certificate request sent to you. Be sure you are part of the creation process to ensure those keys are protected.
• Place a Basic Constraint restriction in your environment that will make your existing 2 or 3 tier PKI that maximum number of tiers in the PKI. This will require the appliance to get it’s certificate from a higher CA in the chain. This will add more complexity to the enrollment and renewal process, but will remove the ability for anyone to easily get a subordinate CA certificate. It can also be done in a way that the appliance winds up as the bottom of the tier depth of the Basic Constraint as well – further limiting the exposure of the CA certificate on the appliance.