TL;TR: Don't get wild for no reason. Take instead a look at the certificate. pathlen=0
I doubt that this certificate will be used on BlueCoat appliances to MITM connections. It has a pathlen of 0 which means that it can be used to sign leaf certificates (i.e. for servers) but it cannot be used to create an additional CA. Thus in order to use this CA certificate for MITM on BlueCoat devices BlueCoat would install this certificate including its private key on all BlueCoat devices which would quickly expose the private key to the public.
I think that this certificate is more used inside BlueCoat's own infrastructure, i.e. to sign their companies certificates. This would be similar to what Google and others do for a long time already. And with a similar setup, i.e. "Google Internet Authority G2" has also a pathlen=0.
That's a ridiculous claim. It would be trivial to implement a MITM-as-a-service on a server that Blue Coat devices can connect to. You're providing factually incorrect information.
> Thus in order to use this CA certificate for MITM on BlueCoat devices BlueCoat would install this certificate including its private key on all BlueCoat devices which would quickly expose the private key to the public.
They can simply expose a cert issuing service over the internet.
That's actually a possibility but I very much doubt this would be used in practice. Apart from the scaling problem there is a more serious problem which would make use of this certificate for lots of MITM impossible:
- today's browsers use certificate pinning, i.e. Chrome, Firefox... have predefined lists of sites where they know which public key to expect. One example of such a site is google.com.
- The browser will usually complain if the certificate for this site is not the expected one.
- The browser will not complain on pinned certificates if the CA issuing this certificate was explicitly added as trusted into the browser. This is to allow legal SSL interception, i.e. the one done in lots of companies to protect against malware and data leakage and done by several desktop AV products for the same reason.
Thus, if the certificate is signed by the BlueCoat CA which is implicitly trusted due to derived trust then the browser will complain because the certificate does not match the expected (pinned) one. If instead the certificate was signed by an explicitly installed CA the browser will not complain.
That's actually the way the usage of misissued certificates in Iran was detected (ComodoHacker). So this behavior would make the use of this BlueCoat CA for many MITM attacks impractical.
> today's browsers use certificate pinning, i.e. Chrome, Firefox... have predefined lists of sites where they know which public key to expect. One example of such a site is google.com.
Yes, this may be true, but the list is quite small. You may not be able to trick Chrome into connecting to a fake google.com certificate but there's lots other "high security site[s]" as Adam Langley suggests[1] should apply when they opened this up:
> Can I get this for my site? If you run a large, high security site and want Chrome to include pins, let me know.
The reason why this list is small is because key pinning in practice is difficult — and risky. Look to comments on Twitter from Sleevi et al. as to how easy it is to shoot yourself in the foot. HPKP is a terrific idea, but has complicated implementation challenges.
