
Symantec Issues Intermediate CA Certificate for Blue Coat Public Services - AaronFriel
https://crt.sh/?id=19538258
======
AaronFriel
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.

[1] - [https://security.googleblog.com/2015/09/improved-digital-
cer...](https://security.googleblog.com/2015/09/improved-digital-certificate-
security.html)

[2] -
[https://en.wikipedia.org/w/index.php?title=Blue_Coat_Systems...](https://en.wikipedia.org/w/index.php?title=Blue_Coat_Systems&oldid=721816010#Controversy)

~~~
MichaelGG
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/\--](https://www.elastica.net/cloudsoc/--)
or maybe I'm misunderstanding what it does?

~~~
mrb
Yes they have a cloud service: [https://www.bluecoat.com/products-and-
solutions/global-cloud...](https://www.bluecoat.com/products-and-
solutions/global-cloud-operations)

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.

~~~
JoshTriplett
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.

~~~
TechnicalVault
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.

~~~
jeremyjh
He isn't talking about the legality of it at all. He is talking about what the
browsers include in their trust store.

------
bigiain
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](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?)

~~~
tombrossman
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](https://en.wikipedia.org/wiki/Convergence_%28SSL%29)

~~~
netheril96
> 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.

------
maulwuff
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.

(this is a copy of my post on reddit/r/netsec).

~~~
throwaway2048
not true, bluecoat devices could simply ask a bluecoat server with the CA for
arbitrary certs.

~~~
maulwuff
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.

~~~
prdonahue
> 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.

[1]
[https://www.imperialviolet.org/2011/05/04/pinning.html](https://www.imperialviolet.org/2011/05/04/pinning.html)

~~~
maulwuff
While the list is definitely incomplete I would not call it small. Have a look
at
[https://chromium.googlesource.com/chromium/src/net/+/master/...](https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json)

~~~
throwaway2048
its easy to discover whats on the list by people doing mitm...

------
Aoreias
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].

[0] [https://security.googleblog.com/2015/10/sustaining-
digital-c...](https://security.googleblog.com/2015/10/sustaining-digital-
certificate-security.html)

~~~
lallysingh
I'm hesitant to relax here. Blue Coat's got a nasty history of making money
off of the regimes that'd do this without hesitation:

[https://www.newsrecord.co/us-based-internet-surveillance-
tec...](https://www.newsrecord.co/us-based-internet-surveillance-technology-
used-by-authoritarian-regimes/)

~~~
Aoreias
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.

~~~
lallysingh
Between the time of issue and renovation, a lot of people can get arrested,
monitored, or blackmailed.

~~~
glasz
that's how the beautiful rule of law works. damage done, people killed,
complaint rejected, "overruled".

------
CiPHPerCoder
[https://archive.is/FEZfj](https://archive.is/FEZfj) just in case this goes
down.

How to untrust this certificate: [https://blog.filippo.io/untrusting-an-
intermediate-ca-on-os-...](https://blog.filippo.io/untrusting-an-intermediate-
ca-on-os-x/)

~~~
calgoo
Its funny how reluctant I am to install the certificate in the first step. I
know it works as a vaccine of sorts, but still. It feels wrong.

~~~
scintill76
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.

------
vardump
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?

Remember that also Thawte is their brand.

Incredible.

------
taylorbuley
Assad's Syria, among other newsworthy nations, is reportedly a BlueCoat
customer.

------
glenjamin
This sounds like a good time to mention [https://perspectives-
project.org/](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.

~~~
netheril96
> 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?

------
0x0
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).

------
0x0
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.

~~~
inopinatus
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.

~~~
0x0
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.

------
StavrosK
So, how much of my internet will break if I distrust the Symantec cert on my
machine?

~~~
vox_mollis
If your threat model contains nation-states, you shouldn't be trusting any CAs
in the first place.

With a nation-state adversary, you really need to be manually verifying
certificate hashes that have been securely communicated to you out of band.

~~~
bigiain
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.

~~~
vox_mollis
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.

Nobody ever said privacy was convenient.

~~~
bigiain
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](https://mybank.com),
but the certificate identifies it as mybank.suspiciouscorp.net Continue anyway
(not recommended): [OK] [Hell no!]"

~~~
Spooky23
If you have a problem with that, use your own network.

~~~
TechnicalVault
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?

~~~
Spooky23
Sounds like you have a contract problem with the vetted individual.

------
knd775
Oh hell. This can't be good.

------
supergeek133
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.

------
dang
Also
[https://news.ycombinator.com/item?id=11781875](https://news.ycombinator.com/item?id=11781875).

------
josephlord
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.

~~~
svenfaw
Bear in mind that Symantec also owns Thawte.

------
mikecb
'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.

~~~
kerkeslager
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.

~~~
mikecb
Seems like it would have unacceptable performance limitations.

~~~
kerkeslager
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.

~~~
mikecb
I didn't say that at all.

~~~
kerkeslager
Okay, so what did you mean when you said, "Seems like it would have
unacceptable performance limitations."

------
mtgx
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)

~~~
pfg
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].

[1]: [https://groups.google.com/a/chromium.org/forum/#!topic/ct-
po...](https://groups.google.com/a/chromium.org/forum/#!topic/ct-
policy/hNKxsHIO8gU)

------
glasz
once again, evidence how completely broken the ca system is. let the blame
game begin.

