It's not clear to me why Blue Coat would need to be a trusted CA by all systems and browsers, but given their own checkered history I don't think it would be unreasonable to suggest they're going to use this for MITM purposes.
 - https://security.googleblog.com/2015/09/improved-digital-cer...
 - https://en.wikipedia.org/w/index.php?title=Blue_Coat_Systems...
Edit: This product says it does real-time traffic analysis for user transactions. It's understandable they want to make this as easy for customers as possible, just like CloudFlare. https://www.elastica.net/cloudsoc/-- or maybe I'm misunderstanding what it does?
If they just need to issue lots of certificates, or make it easy for client devices to get certificates, or even for their own cloud services, they could use LetsEncrypt.
There are very few use cases where having your own CA is necessary, and for a company like Blue Coat, those reasons seem primarily nefarious.
The most important thing to pay attention to here, with respect to Blue Coat, is the subscriber agreement they have signed with the CA AND the CPS that they write for their auditors. It'll dictate what they are and are not allowed to do with this subCA. If these are publicly trusted certificates, they will still need to pass—at minimum—domain control validation, e.g., can BC/their customers add an arbitrary DNS record or HTTP-accessible file for the zone being issued? If not, CA/B prohibits their issuance, so Symantec would get in huge trouble for allowing this. When you run your own subCA you are supposed to perform these checks yourself; it's up to their auditors (more in a sec) and Symantec to make sure they are performing these each and every time.
Additionally, Blue Coat will need to pass a WebTrust audit as mandated by the CA/B Forum. The thoroughness of this audit depends on how much Blue Coat is taking over from Symantec. If they're, e.g., handling key material, the audit will be much the same the CAs themselves must do. If doing considerably less, the scope of the audit is considerably more constrained. I think these audits are released to the public as I remember Let's Encrypt doing so, but that may just be because i) they aren't a full blown directly browser trusted CA or ii) LE just decided to do so as it fits their ethos.
You can find the relevant regulations that are imposed on public CAs here (look specifically for references to Subscriber Agreements): https://github.com/cabforum/documents/tree/master/docs. I'd start with the "BRs" (Baseline Requirements) doc; the other, EV Guidelines are irrelevant here, and Bylaws apply to CA/B itself.
Source: I manage CloudFlare's relationship with CAs and product manage our SSL/TLS related offerings.
EDIT: Added reference to CPS, the Certification Practice Statement. This document is written and provided to the auditors, and includes controls to test, etc. Here's Symantec's for example (as linked within X509v3 in crt.sh): https://www.symauth.com/cps.
Head of Let's Encrypt here. We're required to publicly disclose our annual audit reports, as are all publicly trusted CAs.
No comment on this particular situation since I don't know enough about it, but I'd expect any organization with a publicly trusted intermediate to have a CP/CPS publicly available prior to getting the intermediate.
Your comment is like discovering the fox has been given the keys to the henhouse and saying "Maybe the fox just wants to hang out with the hens".
I suspect it will be less than 18 months. And 99% of the people will be 'shocked' :-)
In fact, other than running a legit CA service, using this intermediate CA to intercept and decrypt traffic on their cloud is the only acceptable use of the intermediate CA I can think of, as long as they disclose to their cloud customers that they MitM TLS connections. After all, Blue Coat's cloud is their network, so they have the right to operate it the way they want.
Any other use of the intermediate CA would be highly irresponsible/dangerous. For example if they used it in their SSL Visibility Appliance, any owner of the appliance could extract the CA private key from the appliance.
If you want to MITM traffic on your network, have clients install your MITM certificate, which gives them ample warning about what you're doing.
The last time Symantec made a "mistake" with their CA (https://security.googleblog.com/2015/10/sustaining-digital-c...), Google said "Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency." Interesting wording, "by Symantec itself". And now, a few days before June 1st, Symantec issues an intermediate CA certificate to a known vendor of MITM systems, so that Bluecoat can issue certificates themselves rather than having their "certificates issued by Symantec itself".
I wonder if Bluecoat will support Certificate Transparency?
Even that is silly - they don't need to be an intermediate CA to do that. Just require that their customers install a custom certificate.
I say "virtually" as if they do, Google will drop the hammer on them (again), this time a much heavier one. It's a business risk I just don't see them taking — they have too big of a revenue base to jeopardize it this way.
If they have clients on their network they want to MITM then that's not a legitimate use case for a CA at all. It doesn't matter if everything is on their network, it's unacceptable that my browser accepts their signature.
Assuming browsers are willing to actually follow through and do so, yes.
My guess is they'd settle for blocking certs issued after a specific date, at least for a transition period. The alternative would block too much of the internet.
Ryan takes egregious violations of the BRs quite seriously. The CAs cross Google at their own risk. One day you find you're not trusted in Chrome anymore and their goes your business.
At a minimum they could block EV certs from being honoured as EV which harms reputation and prevents a profitable line of business.
This is exactly the sort of thing I'd like to have the "CA death penalty" seriously considered against Symantec - but I fear they're going to be judged "too big to fail". A grass roots campaign of contacting sites (especially sites I've got paid accounts with) saying "Sorry, I can't use your site anymore because I've had to disable Symantec's root keys (see this link for reasons), can I please cancel my billing." might be the only thing I can do.
(Oh, and joy! https://www.apple.com is secured by a Symantec cert for me right now. How much would you bet against all my Mac OS X and iOS software updates also being "secured" that way?)
I have gone into Firefox's settings and deleted random certs like the Hong Kong Post Office and this didn't break any of the sites I use, but all certificates are re-installed each time Firefox updates.
Thinking more globally, someone living in Hong Kong might prefer to keep the Post Office one but distrust all American CA's from their browser and they should be accommodated too.
Imagine treating the set of trusted CAs in your browser just like your ad blocker's filter list. You would damn sure need a trustworthy curator to maintain that list, but it seems doable (in my admittedly non-expert and humble opinion). Does such a thing exist? Moxie's Convergence extension is the closest thing to it that I'm aware of: https://en.wikipedia.org/wiki/Convergence_%28SSL%29
Even a (mainland) Chinese user won't be able to distrust American CA's and still browse the Internet fine, and it is known that China's network is one of the most isolated one on earth filtered by the GFW. For example, Baidu's certificate is signed by Verisign, Taobao by GlobalSign, QQ by GeoTrust. All of those certificate authorities all headquartered in the United States.
CA's like Symantec is just too big to fail, even if your proposal is implemented.
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.
(this is a copy of my post on reddit/r/netsec).
They can simply expose a cert issuing service over the internet.
- 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.
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 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.
That said, I'm quite curious though if Google is going to require that Blue Coat submit all issued certificates to be submitted to Certificate Transparency logs like the rest of Symantec's certificates.
If Symantec didn't revoke the certificate then it would almost certainly lead to their root certificate being untrusted by major browsers and destroy their entire certificate business.
So why doesn't Blue Coat establish their own CA for this purpose?
Legitimate uses of this would be things like government or military departments intercepting traffic from their own network.
As explained elsewhere in this thread, they have a history of working with regimes where they want to intercept the traffic of the general public in countries.
And even if they are bound by Symantec's CPS, they can do a lot of damage before the CPS can be enforced.
How to untrust this certificate: https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-...
Unless there's something that can explain this in better light, it's time to untrust Symantec brands and stop purchasing their certificates. Is it really that VeriSign, one of the pioneers in CA industry, cannot be trusted anymore?
Remember that also Thawte is their brand.
I think it's been a little bit inactive of late, due to poor takeup - but it would certainly benefit from more users and more people contributing to the project.
I just checked out the website, and found it interesting. And then I found it only has a Firefox extension, but not a Chrome extension. Given that the Chrome's market share is several times that of Firefox globally, maybe that is the reason of the poor takeup?
By testing the DNS, you really verify the domain operator, which in practice means anyone who can update the NS/DS/glue records. It's arguably quite a weak assertion.
Similarly this explains why DV certificates are cheap and EV certificates are less cheap.
With a nation-state adversary, you really need to be manually verifying certificate hashes that have been securely communicated to you out of band.
"Blue Coat products are primarily used by enterprises, schools, hospitals, governments, and public agencies to block malware and malicious threats, control access to applications and content in the workplace, surveillance, censorship, and improve the performance of network applications."
I'm resigned to acknowledging that if the NSA (GHCQ/ASD/insert-local-equivalent at least for five-eyes nations) wants to investigate _me_ specifically, I'm fucked and my only option is to not use the internet (or telephones or mail or or or).
I'm not (yet) prepared to give up and hand that level of access to my digital life to enterprises, schools, (most bits of the) government, or public agencies.
A good number of employer or school-provider devices will have their own certificates preinstalled anyway.
Nobody ever said privacy was convenient.
I'm _not good with a school or employer's network being able to generate arbitrary certs for my email, bank, social networks, etc - WITHOUT ME KNOWING ABOUT IT ON MY PERSONAL DEVICES... Sure, MitM me if it's your network - but I 100% should be able to rely on my browser on my device reliably being able to tell me "You're attempting to visit https://mybank.com, but the certificate identifies it as mybank.suspiciouscorp.net Continue anyway (not recommended): [OK] [Hell no!]"
But if an attack can work on you using my network, it is also an attack that works on me surreptitiously rerouting your traffic onto my network. Basically undoing HTTPS.
Also, what I'm talking about (MITM proxy on a private network), it's not sneaky -- you will get unsigned cert warnings. If you are using an employers device, you won't see warnings, but can examine the SSL certificate. You should also assume that you are being monitored.
No you wont. Bluecoat now has a CA Cert root key signed by Symantec. If they issue a .google.com or .gmail.com ssl cert you will _not_ get an unsigned cert warning.
And explain to me how to connect to, say, my internet banking without using "a private network"? Every single hop between my house(or my phone) and my bank is a piece of network owned by some company or other. "Use your own network" is meaningless in the context of connecting to any hardware you don't own yourself.
If you provide a publicly accessible "Guest" network isolated from my corporate or private resources, that I agree that it's unreasonable to intercept TLS sessions.
If you are on my network, which exists to serve my constituents with a personal device, I have every right to or even have a duty to ensure that you aren't threatening the overall integrity of the private network. Whether that be exfiltrating data, bringing in malware, etc.
In 2016, the answer to this issue is really simple -- bring your own cellular service.
If someone doesn't want to install the root cert, then "use your own network" is a perfectly fine response.
If someone is upset that the TLS security model is broken in half, then "use your own network" is not a valid response.
Comodo and Synantec are 32% each, then goes others. StartSSl is significant but 2%, Let'sEncrypt tiny for now: https://w3techs.com/technologies/history_overview/ssl_certif...
Let's Encrypt's root is not trusted by any browser yet, so they got a cross-signature from IdenTrust. So far, basically everybody using Let's Encrypt chains to the IdenTrust root.
Given that IdenTrust grew from "<0.1%" to 5.6% since the launch of Let's Encrypt, and the shape is roughly the same as https://letsencrypt.org/stats/ , I strongly suspect that the 5.6% market share credited to IdenTrust actually belongs to Let's Encrypt.
As a check, we can divide 2/3 of the total unexpired Let's Encrypt certificates (~2.8M as of last week, 2/3 because standard practise is to renew a 90 day cert after 60 days, so 1/3 are probably overlapping = 1.86M) by the total number of https sites (I had a hard time finding this, but http://arstechnica.com/security/2016/03/more-than-13-million... claims that 5.9M is 17% of https servers, so 34.7M), and we get 5.4%, which is almost the same number as the IdenTrust number above.
That's still nowhere near Comodo, but it's not completely insignificant.
This is correct. (Source: I run Let's Encrypt)
I'm not even convinced it would have performance limitations. Let's say Alice and Bob are communicating and Eve has the BlueCoat device in the middle. Alice sends the initial connection request to Bob, but Eve gets it instead. Eve then sends a new initial request to Bob AND a request to the BlueCoat server to get the fake cert in parallel. As long as the BlueCoat server responds with similar latency to Bob, Alice won't see any significant difference in latency as compared to Eve simply forwarding the requests.