I'm posting this because within the past year, Symantec has gotten in hot water for issuing rogue certificates[1]. While Symantec has agreed to certificate transparency, Blue Coat is a known operator of MITM services they sell to nation-states, and this certificate would allow Blue Coat to issue arbitrary MITM certificates.
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[2] I don't think it would be unreasonable to suggest they're going to use this for MITM purposes.
They have a cloud services platform, perhaps it's for that? Symantec would get destroyed if they issued a CA cert that was misused, right?
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?
Even Cloudflare doesn't use their own CA, but they have a relationship with Comodo; at least, from what I can tell on services I use with Cloudflare.
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.
We have relationships with Comodo, DigiCert, and GlobalSign. A large part of our Universal SSL issuance is currently through Comodo, which is probably what you noticed. (We've considered acquiring our own CA or subCA in the past but the audit requirements are quite onerous, at least after the first year, and sometimes it's nice to have someone handle certain aspects for you.)
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.
"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."
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.
Thank you. Given that CloudFlare is basically replacing the public internet one site at a time, I feel better that there is at least some third party accountability on your power.
Security is not obtained by optimistically assuming actors are using their capabilities for good. Sure, there are legit ways they could use this, but the entire point of CAs is that they be trusted actors, and there are very strong reasons not to trust Blue Coat.
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".
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.
It's acceptable (albeit a terrible practice) to MITM traffic on your own network. It's not at all acceptable for any CA certificate accepted by default in all browsers (not just those on your network), no matter whether root or intermediate, to ever issue a certificate for a domain to anyone other than the owner of that domain. Issuing such a certificate is grounds for immediate revocation of browser trust.
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.
It may be acceptable in certain states and jurisdictions, but it is throughly illegal in others. Remember you aren't just MITMing your own network, if someone from your network connects to my server you are MITMing me too and you have not obtained my consent for that. Even if your state is a one party consent state, mine may not be or have laws that heavily restrict interception.
I'd argue that it doesn't give ample warning. I've seen a number of corporate networks where a MITM trusted root cert is installed on machines via an AD policy and the end users have no clue that their IT department can see things like their banking passwords. Unless you examine the cert by hand or connect a device without the cert to the network, you would have no idea this is going on.
Assuming that Symantec doesn't manage to deflect onto Bluecoat, and assuming that browser vendors are willing to actually revoke one of the largest CAs for misuse rather than wagging their finger.
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?
> 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.
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'm unclear about what you're saying. Are you saying it is OK for them to MITM traffic to https://google.com on their network by issuing a google.com cert? That is definitely not OK. If they only issue certs for domains that belong to themselves or their customers, that is OK.
Notwithstanding key pinning (which I believe is even overridden by installed private roots), they can issue for google.com as long as they want so long as they get their users to install a private root.
This, MITM using voluntarily installed trust anchors is one thing and explicitly allowed by google, creating a certificate for google.com that will be accepts by all TLS clients is not and Symantec have got in trouble before for doing this.
Completely agree. But there's virtually no way Symantec would turn them loose without confidence in their audit and controls around issuance processes, domain control validation, etc.
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.
I don't see the legitimate use case here. If they're dealing with inbound TLS connections to their cloud services then they can scan or modify the traffic on the cleartext side of the TLS connection. No need to be a CA.
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.
This would keep the key private, but would not contain the potential for abuse. The appliance owner could still invoke whatever mechanism is used to generate certs for arbitrary hostnames.
The big question is does the emperor have any clothes?
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.
Trust me, Google would take action almost immediately after realizing what happened (if this were to actually go down). Take a look at Ryan Sleevi's previous posts on Symantec:
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.
Blue Coat need only issue MITM certificates for one large client for a few days to both do a lot of damage and make a lot of money, and if that's their plan, what do they care if they aren't trusted in Chrome afterward?
I wonder just how many certs I'd notice failing if I pulled Symantec's root out of my keystore - and if I'd get any mileage contacting the sites that end up broken and explaining why.
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?)
What I would really like to see is a curated list of CAs and intermediates instead of the huge list my browser currently trusts. Preferably a browser extension like EFF's Privacy Badger, to make it easier to use.
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
> but distrust all American CA's from their browser and they should be accommodated too.
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.
Maybe a browser extension that generates this email automatically to automatically send to the screen-scraped contact-us web email address/form? "Hi, I use bigiainDisconnectAdblockPlus-thingy and just wanted to let you know I didn't visit your site because I can't trust your certificates, which come from Symantec. Here's the fingerprint of that cert xxxxxxxxxxxxxxxxx and here's why I can't trust it <link to explanation/tirade/manifesto>"
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.
This isn't necessarily as nefarious as it seems - Blue Coat is going to have to comply with Symantec's Certification Practice Statement(CPS) which prohibits the issuance of MitM certificates. In all likelihood it's to allow Blue Coat to roll out a service that allows it to create certificates for clients of its security services. Any deviation from that CPS would necessitate revoking this intermediate certificate.
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[0].
Sure, but if they started issuing MitM certs ANYWHERE then Symantec would have no choice but to revoke the CA's certificate. It doesn't matter if the CA was functioning for a corrupt regime or a well-intentioned business legitimately MitM'ing employees traffic.
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.
This is a baby step in the direction of legitimate MITMing of SSL, which is something many of Blue Coat's customers would love. SSL's entire security profile is built around trust in a huge number of CAs, and if Blue Coat and other can persuade one to allow this in any form then SSL is fundamentally and permanently broken (without pinning or out of band checks) for pretty much all users except highly technical ones.
> In all likelihood it's to allow Blue Coat to roll out a service that allows it to create certificates for clients of its security services. Any deviation from that CPS would necessitate revoking this intermediate certificate.
So why doesn't Blue Coat establish their own CA for this purpose?
Are you saying they should become a new root CA? That is a huge amount of work, and would require them to convince all browsers and OS's to make them a root CA, which many would be reluctant to do.
If you're building an interception service (which this could be) - then yes, you build your own Root CA which you install on devices that you want to intercept.
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.
No, it would require them to add their cert on the intended machines under their control. The only reasons they would need the trust of all browsers and OS's are subterfuge and laziness. They should not be globally trusted to issue certificates.
You're making a lot of assumptions about the terms under which this certificate was issued, which you don't know. Without seeing the contract between Symantec and Blue Coat you can't claim that they're bound by Symantec's CPS.
And even if they are bound by Symantec's CPS, they can do a lot of damage before the CPS can be enforced.
The certificate has this in it, which would seem to confirm what you're saying: "Explicit Text: In the event that the BlueCoat CPS and Symantec CPS conflict, the Symantec CPS governs."
If you already have the signing Symantec cert trusted (likely), installing and even trusting that one doesn't make you more vulnerable than you already were. That's why it's troubling.
What was Symantec thinking? Doing decisions that undermine their whole business?
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?
This sounds like a good time to mention https://perspectives-project.org/. It augments the standard CA trust model with one based on figuring out what certs everyone else is seeing, and whether or not that's changed recently.
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 think it's been a little bit inactive of late, due to poor takeup
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?
It really sucks that there's no way to block this intermediate CA or even the root symantec CA on iOS; the type of roaming device where it's most needed (and most likely to be used with random wifi).
You know, the main job for a web CA is to verify the owner of a domain. What if... domain registrars had that job instead? They definitively know the domain registrant, no need to play games with email verification tokens or http challenges.
Domain registries & registrars do not generally verify the identity of the registrant. It can occur, but only if trademark protection mechanisms are invoked.
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.
I was talking about DV certificates. The registrar is in the perfect position to provide this. You could probably even set it up so nobody but the real registrar can issue certificates for a given domain, as opposed to the current free-for-all.
Not really, it could be set up so registrar CAs would only be valid for domains they are registrars for. Then you just need to pick one trustworthy registrar for your own domains, and you're set. If you can't trust your registrar with your domains, you have bigger problems anyway.
Sure - but from the (to be taken with appropriate credibility rating) WikiPedia page for BlueCoat:
"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.
Ok, so if your adversary is your employer or your school, you are presumably using a network not controlled by you, in which case your endpoint ought to already be a VPN.
A good number of employer or school-provider devices will have their own certificates preinstalled anyway.
I'm good with my work or school owned/issued device trusting a root cert installed by that device's owner.
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!]"
What if the site they're connecting to has a problem with that? If I for example serve E-Healthcare records, and have an agreement that a given person that I have vetted has access to them, I might have a problem with your unvetted IT staff having access but how would I know?
I agree that people running the network have the right to run it as they want.
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.
As a private network owner, I see risk in uncontrolled SSL.
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.
The objection is not to controlling TLS on a private network. The objection is to using a method that can silently intercept connections to devices you don't administrate.
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.
And what do I do when you get a job at my cellular provider, and decide that my internet banking or healthcare website connections might be me "exfiltrating data" and you choose to take it upon yourself to inspect the contents of those connections just in case I'm somehow "threatening the overall integrity of the cellular provider's network"?
All sysadmins have nation-states as their threat model (or at least they should have it). If spy agencies can in any way leverage your network, then you're an automatic target.
I'm not able to find the methodology for the w3techs report, but I suspect they only count the ultimate root, not any intermediates.
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.
"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."
This is very much a case of "the who not the what"... they've been in some shady dealings with countries that explicitly have goals to deny freedom of information.
I'd forgotten that Symantec had acquired Verisign at some point and they are huge certificate supplier. I was planning to untrust Symantec but not sure that is feasible for the Verisign certs too.
'azet noted in another forum that with pathlen:0, this cert cannot be used to issue other intermediate certs, such as they would to place in a traffic inspection device.
Blue Coat can trivially work around this limitation by placing the intermediate cert on a server. Now when the traffic inspection device wants a (leaf) cert, it calls home to the server and the server provides it.
That's your source of security? Performance limitations?
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.
Isn't the dead-line for Google removing Symantec from Chrome supposed to be this June? (if they don't adopt CT for all of their certificates by then, that is)
Google hasn't said anything about removing Symantec under those circumstances. Failing to publish a certificate will result in a browser warning for visitors beginning June 1st[1].
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[2] I don't think it would be unreasonable to suggest they're going to use this for MITM purposes.
[1] - https://security.googleblog.com/2015/09/improved-digital-cer...
[2] - https://en.wikipedia.org/w/index.php?title=Blue_Coat_Systems...