
Google warns of unauthorized TLS certificates trusted by almost all OSes - shawndumas
http://arstechnica.com/security/2015/03/google-warns-of-unauthorized-tls-certificates-trusted-by-almost-all-oses/
======
pilif
Just revoking the intermediates is not enough. This tells the main culprits
that it's ok to issue intermediates to do whatever and then deny
responsibility as it gets detected.

The only possible course of action is to hold the root responsible and to
remove them from the trust store.

The CA system is fragile enough as it is and only the prospects of immediately
going out of business can be any deterrent for CAs not to start doing shady
stuff.

Yes. Revoking the root is annoying for customers of that root, but I'm sure
other CAs will gladly offer a free or really cheap replacement program. And if
the affected root is REALLY big, then just pre-announce the revocation for a
year or two. Just like what Google is doing with the sha1 certs.

~~~
methou
I have marked CNNIC root cert untrusted on all of systems I can control. It
bothers me sometimes when some providers with "good" reputation uses them,
like azure china. I had to manually add the server certificate to trusted
list, just to manage my vms. Otherwise, I barely notice the issue.

It looks that even CNNIC certs themselves weren't widely deployed, correct me
if I'm wrong, most of Chinese sites who wants to employ TLS doesn't do it
right, for example, 12306 has its own root and some sites I use daily has a
self-signed CA with random input in all of the fields.

~~~
higherpurpose
If you think the company that has agreed to collaborate with a Chinese company
to make a different version of Skype (Tom-Skype), for the _sole purpose_ of
letting the Chinese government spy on Chinese citizens' communications in
real-time, can be "trusted" to not have backdoored cloud services in China,
then I have a bridge to sell you.

Microsoft has proven again and again that it's willing to make _any_
concessions to the Chinese government if there's the slightest chance of them
making an extra percent market share in China. We saw that when Google was
hacked by the Chinese government, too. Microsoft was more than happy to agree
to all the censorship policies Google didn't, because it meant that _maybe
possibly_ that would earn them some market share in China, after Google would
be gone - it didn't anyway. Baidu took all that difference Google lost.

~~~
Steuard
This isn't just about earning market share in China. Just about any
organization that operates in China (or hopes to) has a vested interest in,
e.g., having reliable email access there. If your company uses Google products
for email, etc., then these days you'll have some real challenges making them
work for folks over there. Microsoft can capture a lot of _American_ business
that way. (Concrete fears about employees losing crucial access tend to
outweigh philosophical arguments about government surveillance when folks sit
down to make these decisions.)

------
geofft
[http://googleonlinesecurity.blogspot.com/2015/03/maintaining...](http://googleonlinesecurity.blogspot.com/2015/03/maintaining-
digital-certificate-security.html)

is a better URL. (For potential future reference, the current URL is
[http://arstechnica.com/security/2015/03/google-warns-of-
unau...](http://arstechnica.com/security/2015/03/google-warns-of-unauthorized-
tls-certificates-trusted-by-almost-all-oses/) )

~~~
falcolas
I disagree, in this case the direct link is not a better URL. The Ars Technica
article (as many issues as I have with them) correlates not only the Google
alert, but also followup conversations on Twitter and from Mozilla. This kind
of correlation (and analysis) is the very definition of adding value added.

It also clearly links to the Google blog, so it's hard to accuse them of
trying to co-opt Google's content as their own.

------
GauntletWizard
The fact that it's CNNIC that has issued these dangerous certificates is not
exactly relevant to the problem at hand; More than one root authority has made
mistakes in delegation, and several have made the mistake of not checking the
delegation bit and allowing third-parties to request intermediate
certificates.

Still, it bears repeating that CNNIC, which is effectively a branch of the
chinese government, has a root certificate trusted by default in all the major
browsers. Unless you regularly visit chinese websites, you should remove CNNIC
from your browser trust list.

~~~
pbhjpbhj
I'm on FF 36.0 on Kubuntu 14.10 - I removed the certs for CNNIC and then to
test went to the CNNIC website and rewrote the address as https. Website still
shows the lock symbol and still shows the cert verified by the CNNIC root
CA?!? Seems the removal is slightly glitchy somehow, third time worked.

2 things I notice:

1) there are a lot of default trusted suppliers, seems that this should
perhaps be selected on install (trust all or trust local [geographic] or trust
by selecting regions).

2) that unlike with cookies you don't get a record of how often a certificate
(or CA) has been used - so I can't tell from looking at the certificate
information FF holds whether I've ever used the dozen or so Turkish certs for
example; this seems like useful information for users that's not being
displayed. I only use Turkey as an example because I don't use Turkish
websites [I barely know a handful of Turkish words] nor AFAIK any Turkish
company's English language sites.

Why would I need to trust geographically and linguistically distant CA's by
default? If I decide to do something with a .cn site that needs a https
connection it seems that I should be able to get info like "these CA - you
already trust - in turn 'trust' this CA which certifies the site you are
accessing". That along with any warnings the browser wants to give on malware
or phishing then would feed in to a decision to accept the cert and interact
"securely" with the site in question. The sites I actual need secure
transactions with are probably certified by less than a dozen CA; trusting
hundreds by default then seems poor security practice [to this layman].

~~~
tptacek
I'm not thinking very hard about it, but that second bullet sounds like a
_really good_ idea.

~~~
geofft
Looks like Mozilla has this data in aggregate, if I'm understanding this web
page right:

[http://telemetry.mozilla.org/#filter=nightly%2F39%2FCERT_VAL...](http://telemetry.mozilla.org/#filter=nightly%2F39%2FCERT_VALIDATION_SUCCESS_BY_CA%2Fsaved_session%2FFirefox&aggregates=multiselect-
all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Table)

Ignore the graph and match up the table below with this C array:

[https://dxr.mozilla.org/mozilla-
central/source/security/mana...](https://dxr.mozilla.org/mozilla-
central/source/security/manager/boot/src/RootHashes.inc)

If I'm understanding the meaning of "Bin Number" right, not all of the 0s are
surprising. But some are. For instance, the AOL CA hasn't been used to sign
any certs that have been seen. (I guess, in a sense, that's not really
surprising...)

I'd be cool if someone better at front-end than I could present the data with
useful labels, and also mark each CA by whether it's in the non-Mozilla roots.

~~~
mccr8
You can look at the local telemetry for your current Firefox session,
including this variable, by going to about:telemetry, which sort of gets you
what pbhjpbhj was looking for, albeit in an inconvenient and limited fashion.

~~~
pbhjpbhj
I have telemetry upload turned off which appears to then not gather the data
(which is perfectly reasonable) rather than just not upload it.

------
Jonhoo
FWIW, here's what I just did on my (Arch) Linux machine:

    
    
      $ for f in /etc/ssl/certs/*.pem; do sudo ln -sfn "$f" /etc/ca-certificates/trust-source/blacklist/; done
      $ sudo update-ca-trust
    

This will block all currently installed CAs (as well as double-block some, but
that doesn't really matter). You then need to add them back in.

Restart your browser, and go to websites you access frequently (change them to
[https://](https://) if necessary). Click the (broken) padlock and read off
what CA they used; remove the corresponding .pem file from the blacklist
directory. Some might be signed by intermediate certs and thus hard to find,
but SSL Hopper has a great chain inspection tool at
[https://www.sslshopper.com/ssl-checker.html](https://www.sslshopper.com/ssl-
checker.html) you can use to identify the topmost CA cert you need to
whitelist.

After you're done, run "sudo update-ca-trust" again, and restart your browser.
All normal sites should work, and you've gotten rid of ~160 root certs.

If it's of interest to anyone, here are the ones I whitelisted to get all
sites I bothered to try up an running:

    
    
      $ sudo rm DigiCert_* GeoTrust_* Go_Daddy_* GlobalSign_* VeriSign_* StartCom_Certification_Authority* Comodo_* AddTrust_* Thawte_* thawte_Primary_Root_CA* Baltimore_CyberTrust_Root.pem UTN_USERFirst_Hardware_Root_CA.pem Visa_eCommerce_Root.pem
      $ ls /etc/ssl/certs/*.pem | wc -l
      206
      $ ls /etc/ca-certificates/trust-source/blacklist/
      163
    

EDIT: Note that this is not a perfect solution; the CAs you've whitelisted
could still go bad, and you'll need to blacklist any new CA certs that are
added with subsequent ca-certificates updates. But it's a start.

~~~
kpcyrd
Be careful, this has no effect if you're using firefox/iceweasel. They bring
their own set of trusted CAs and ignore all changes on the OS trust store.

------
PythonicAlpha
Action is really needed. A system that can be breached just by any CA company
that is more interested in money than in security (also at least one big CAs
has a bad history concerning security) is plainly broken. There should at
least be a kind of overseer that has the ability to intervene when bad
behavior is reported.

In the current situation, it is impossible to trust this "system of trust". It
just sounds similar as I shall give the keys to my house to the thieves guild
to prevent burglaries.

~~~
geofft
Certificate Transparency is a solution. It's not my favorite solution, but
it's far and away my favorite solution that stands a chance of working.

[http://www.certificate-transparency.org/](http://www.certificate-
transparency.org/)

This particular bad behavior, like entirely too many other breaches, was
(probably) noticed because Google's own browser saw illegitimate but valid
Google certificates, and alerted Google through its own channels. CT extends
that to any other site that wants to participate.

CT also requires that CAs disclose every certificate that's signed, including
those signed by intermediates that they give to third parties. This doesn't
make legitimate use of intermediates much more onerous, but it makes MITMing-
proxy use extremely logistically complicated, even if you felt like telling
the whole world you were MITMing certificates.

~~~
itistoday2
> _Certificate Transparency is a solution_

CT would not have prevented these attacks.

Google would be exactly where they are right now: knowing who issued cert, and
that's it.

Short form:
[https://github.com/okTurtles/dnschain/blob/master/docs/Compa...](https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md)

Long form: [https://blog.okturtles.com/2014/09/the-trouble-with-
certific...](https://blog.okturtles.com/2014/09/the-trouble-with-certificate-
transparency/)

(EDIT: How about an honest discussion instead of a downvote? If you disagree,
you are welcome to explain why.)

~~~
geofft
Given the operational difficulty of implementing a transparently-MITMing proxy
in a Certificate Transparency regime, I'm not sure you can say with certainty
that it wouldn't have prevented this attack. Every time you want to MITM a new
site, you need to contact some number of auditors before you can complete the
connection. That sounds difficult to implement reliably and quickly enough for
a MITM to work.

(Not to mention that most off-the-shelf MITM proxies will intentionally not
implement this, since the use case for legitimate MITM proxying involves using
site-specific CAs, not globally-valid CAs, so you'd have to deploy custom code
to go talk to the auditors. And I somehow have doubts that a robust, black-hat
MITM proxy solution will emerge, given that it probably will have only a
handful of users at any given time.)

In any case, it is certainly not a perfect solution. But it is _a_ solution.

I've read that okTurtles blog post before. Insofar as it points out that CT
has limitations, it's generally right. But the okTurtles scheme is much worse:
if a certificate gets compromised, the only recourse is to _pick a new website
name_. I think it's likely that there is _no_ perfect solution here. CT makes
no claims for perfection, but it's a pretty good imperfect solution, and I
think we need that more than we need a nonexistent perfect solution.

BTW: "Resist commenting about being downvoted. It never does any good, and it
makes boring reading."

~~~
itistoday2
> _Given the operational difficulty of implementing a transparently-MITMing
> proxy in a Certificate Transparency regime, I 'm not sure you can say with
> certainty that it wouldn't have prevented this attack. Every time you want
> to MITM a new site, you need to contact some number of auditors before you
> can complete the connection._

1\. Certs don't need to include SCTs, so, end of story.

2\. Even if that was a requirement, they can be faked just like the
certificate.

> _In any case, it is certainly not a perfect solution. But it is a solution._

It doesn't prevent MITM attacks (even Google acknowledges that), so it's not a
solution (if preventing attacks is what you want).

> _But the okTurtles scheme is much worse: if a certificate gets compromised,
> the only recourse is to pick a new website name._

Certificates are not associated with the key to modify the blockchain entry.
So if a certificate gets compromised, you can immediately fix it by updating
the blockchain entry.

> _BTW: "Resist commenting about being downvoted. It never does any good, and
> it makes boring reading."_

If people downvote me for no good reason, I'll point it out to them. Doesn't
matter to me if it bores them. If that's a problem maybe they shouldn't
downvote in the first place? :P

~~~
yuhong
_2\. Even if that was a requirement, they can be faked just like the
certificate._

Huh?

~~~
itistoday2
> _Huh?_

Read the post, it's all there: [https://blog.okturtles.com/2014/09/the-
trouble-with-certific...](https://blog.okturtles.com/2014/09/the-trouble-with-
certificate-transparency/)

~~~
yuhong
Looks like a complex attack, and "not all CAs will necessarily have their own
log." and same for the converse too.

~~~
itistoday2
Legitimate SCTs can be used in attacks just as well (this will probably be the
common case), as explained here:

[https://news.ycombinator.com/item?id=9254713](https://news.ycombinator.com/item?id=9254713)

~~~
yuhong
Yes, CT would only allow detection. Revocation would be a different problem.

------
chaitanya
It is interesting that when the CNNIC root certificate was added to Firefox,
this is exactly what many people had warned against:
[https://bugzilla.mozilla.org/show_bug.cgi?id=476766](https://bugzilla.mozilla.org/show_bug.cgi?id=476766)

~~~
ttflee
IMHO, had Firefox dared remove CNNIC root cert, Mozilla would already been
ousted with their business in China, like Google.

------
willvarfar
Why can the CN registrar sign .com certs?

Why aren't national authorities limited to their country's TLD? I'd imagine
they'd want this, and the public would want this.

Its so obvious, what am I missing?

~~~
danyork
Any CA can generate a cert for any domain. This is one of the problems with
the current CA system.

------
blueskin_
The CA system is fundamentally broken. Centralised authorities are _bad_.

------
acd
Central certificate authorities were all web users put their trust against
money compensation to the CA are a broken security model! Especially in the
new internet security era were we have government hackers with almost
unlimited budgets. Governments will hack into CAs and issue fake certificates
to popular domains that they want to Man in the middle attack and to that we
have no protection. I think the solution is a voting mechanism or digital ID.
So that the engineer working at Google can sign the certificate with a
Corporate Google ID.

Central CAs is almost as broken security as credit cards with the card number
readable in cleartext on the front of the card.

------
nly
If they implemented and enabled DANE in Chromium then we could detect and
render harmless this miss-issuance for our domains via PKIX-TA Certificate
Authority Constraints instead of playing Whac-A-Mole

------
gislifb
Has anyone gone throught the list of root certificates that are trusted in the
browsers/OSes and done some homework on them? Would be interesting to see
what's behind those authorities and also which certificates they have issued.

I see that in the OS X keychain I have 213 "system roots" that are trusted, I
wonder how many of them I really need...

------
_RPM
I've always had the suspicion that my pc had some sketchy certs installed..
what do ya expect from buying a pc with an OS installed from an electronics
retailer..right?

~~~
Buge
I'm pretty sure it's a default install in Windows, so the retailer doesn't
really make a difference.

~~~
ptaipale
The retailer doesn't. The vendor (who chooses what to pre-install) does.

------
blencdr
It's a good point for Firefox to embed is own certificates.

I wonder if there is such unauthorized certs in Firefox manager.

------
danyork
So what do we do to fix the broken CA system? Particularly in a case where a
bogus certificate is issued by an intermediate CA that rolls up to a root CA
that is included in all the major browsers.

It seems to me that we have several building blocks available and it may be a
combination we need:

1\. CERTIFICATE PINNING (HPKP) - example: [http://tools.ietf.org/html/draft-
ietf-websec-key-pinning-21](http://tools.ietf.org/html/draft-ietf-websec-key-
pinning-21) \- if a browser had previously pinned the certs of affected sites
then it would have known that it was going to bogus sites and could have
displayed a warning or prevented the user from going to those sites.

The challenge with pinning is that somehow you have to learn what to pin
before you visit a site, either by having the pinset or certs pre-loaded into
the app/browser or simply by doing Trust On First Use (TOFU). Additionally, if
the first use is to the site controlled by an attacker, the cert that gets
pinned in the browser could in fact be the _attacker 's_ cert, which could
make recovery difficult.

Which brings us to...

2\. DANE/DNSSEC -
[http://www.internetsociety.org/deploy360/resources/dane/](http://www.internetsociety.org/deploy360/resources/dane/)
\- with DANE (RFC 6698) you put a fingerprint (or an entire cert) into a TLSA
record in DNS and then sign that with DNSSEC. A browser or app that supported
DANE could deal with the TOFU issue by doing a DANE check to verify the cert
that it is receiving from the web server. This would then effectively
bootstrap the cert pinning process by providing a way to test the validity of
the cert.

Because the DANE TLSA records are entered by the owner/operator of the domain
and then through DS records are tied into a validated chain-of-trust up to the
root of DNS, it would be difficult for an attacker to subvert this with
his/her malicious TLSA records.

But we have a third layer to help...

3\. CERTIFICATE TRANSPARENCY (CT) - [http://www.certificate-
transparency.org/](http://www.certificate-transparency.org/) \- CT provides a
way to log all the issued certs and have browsers/apps check those logs
through an auditor. When the browser gets the TLS cert, it also gets a signed
cert timestamp (SCT) and can use that through an auditor component to check if
the cert is valid. The challenge is that right now only some CAs log issuance
of certs and only some browsers/apps check via an auditor. (I also don’t
understand myself exactly how real-time CT is, but that may just be that I
need to understand the SCT mechanism better.)

To me these three different components can work together to provide a higher
degree of trust: cert pinning to help with the speed of connecting to
frequently-visited sites; DANE to help with the first use/key learning
issue[1]; and CT to provide another means of checking the cert validity.

Comments?

[1] And yes, DANE could be used to store entire TLS certs separately, but
right now I’m looking at how these pieces could be used together to give the
maximum efficiency and security.

------
DiaaAttia
Hello, I would like to help tutors and students by sharing my experience with
[http://preply.com/en/chinese-by-skype](http://preply.com/en/chinese-by-skype)
I am currently learning Chinese with native speakers over there and the
quality presented is excellent and satisfying

------
methou
The day has come.

------
fensipens
Goodin can't help but say borderline moronic things every once in a while:

 _Defenders of current system for acquiring and and revoking TLS certificates
have recent chafed in response to statements from this author that it 's
hopelessly broken. Besides remembering that almost all of these critics have a
strong financial interest in the way the system works now_

"chafed" because of this:

[https://twitter.com/ivanristic/status/578536108662861824](https://twitter.com/ivanristic/status/578536108662861824)

So Ristic working for ssllabs automatically disqualifies him from asking the
perfectly valid question "What is a better approach, in your opinion?"..

You still like your Goodin, tptacek? ;)

