
Enhancing digital certificate security (Fake *.Google.com cert issued) - cleverjake
http://googleonlinesecurity.blogspot.com/2013/01/enhancing-digital-certificate-security.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GoogleOnlineSecurityBlog+%28Google+Online+Security+Blog%29
======
moxie
If you host a website and are worried about these types of attacks against
your users, there are a couple of fairly straightforward things you can do to
strengthen your position:

1) There is no reason that your mobile apps need to use the public CA system.
You can either generate your own signing certificates and embed them in your
apps, or if you must use CA certificates for your mobile endpoints, at least
pin those SPKIs in your apps. More info here:
[http://www.thoughtcrime.org/blog/authenticity-is-broken-
in-s...](http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-
your-app-ha/)

2) If your website is high volume, Adam Langley is very generous about adding
certificate pins for the CA you are using to Chrome:
<http://www.imperialviolet.org/2011/05/04/pinning.html> This will mean that a
random CA in Turkey can not be used to intercept traffic to your website from
Chrome, in the exact same was that Google was protected in this incident with
its own websites. Word on the street is that Firefox is now beginning to use
the same list of pins.

3) Experiment with and support the development of TACK, which is a way to
frictionlessly pin certificates for your website in a dynamic way (rather than
having to hardcode them into browser binaries): <http://tack.io>

4) And of course, make sure that you're advertising HSTS headers, so that your
users aren't vulnerable to sslstrip
(<http://www.thoughtcrime.org/software/sslstrip>) attacks.

~~~
kevinburke
It seems like "one guy pinning certificates to Chrome" might be an interesting
attack vector. How does he verify you actually work for the high-profile site
in question?

~~~
nwh
Same way they do other verifications I suppose; by proving you have write
access to the server in question. If someone malicious can manage that,
there's bigger problems than SSL.

------
mrb
_"they discovered that in August 2011 they had mistakenly issued two
intermediate CA certificates to organizations that should have instead
received regular SSL certificates"_

This is the worst security violation committed by a CA that I have ever read!
These organizations can now issue certificates for any domain, not just
google.com, and they will be seen as valid by all browsers. Fortunately Chrome
already revoked the intermediate CA certs.

However it is unclear whether TURKTRUST has done so on their side yet or not.
They distribute 2 main CRLs: [1] which is empty(!) and [2] which contains a
bunch of serial numbers recently revoked presumably related to the incident.
However their root cert [3] does not reference any of these CRLs, and their
(legit) intermediate CA cert [4] is also misconfigured and points to the empty
CRL:

    
    
                X509v3 CRL Distribution Points:
                    Full Name:
                      URI:http://www.turktrust.com.tr/sil/TURKTRUST_Kok_SIL_s3.crl
    

What this means is that it appears TURKTRUST has not technically revoked
anything via CRL. Perhaps they did via OCSP, but I have not checked whether
their OCSP endpoint advertises the recent revocations or not.

[1] <http://www.turktrust.com.tr/sil/TURKTRUST_Kok_SIL_s3.crl>

[2]
[http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_s3.c...](http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_s3.crl)

[3]
[http://www.turktrust.com.tr/sertifikalar/19_TURKTRUST_Elektr...](http://www.turktrust.com.tr/sertifikalar/19_TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi.crt)

[4]
[http://www.turktrust.com.tr/sertifikalar/20_TURKTRUST_Niteli...](http://www.turktrust.com.tr/sertifikalar/20_TURKTRUST_Nitelikli_Elektronik_Sertifika_Hizmetleri.crt)

~~~
yk
Worse than the digitask desaster? Just from this talk [1], I can think of two
or three worse behaviours by digitask.

[1]
[http://events.ccc.de/congress/2012/Fahrplan/events/5319.en.h...](http://events.ccc.de/congress/2012/Fahrplan/events/5319.en.html)

------
huhtenberg
I used to be in a contact with a guy who got an intermediate CA certificate,
because he was friends with someone who was at the beginning of Thawte (I
_think_ , it was a while ago). He said he got it as a gift in the early '00s
or late '90s and it had an expiry in 2050 (?). Yep, I too was like O_O

The PKI in its current form and application should really go. Cross-signing of
a certificate by two or more independent CAs would be also a good step
forward. And so would be a native support for certificate pinning in browsers.
In other words, PKI should be used for _bootstrapping_ the trust between two
unacquainted parties, but it shouldn't be the only option, nor should be used
as a trust provider on an on-going basis.

Consider this, if I hold a certificate for fubar.com, why am I not permitted
to issue a certificate for xyz.fubar.com? Or, better yet - another certificate
for fubar.com?

(edit) Also, "Enhancing digital certificate security" is such a bullshit
title. Very odd to see this coming from Google. They must be very unnerved by
the incident, or they are going to use it as a stepping stone to something
else.

~~~
jcase
> Consider this, if I hold a certificate for fubar.com, why am I not permitted
> to issue a certificate for xyz.fubar.com Or, better yet - another
> certificate for fubar.com?

Because business model. StartSSL.com is afaik the first (only?) CA that
charges solely for identity validation and then let's you create unlimited
(wildcard) certificates (with the exception of EV certs).

* No ties, just a customer.

~~~
jrabone
Quite. You, are, of course, free to run your own CA. I rather like my version
(a custom minimal Linux virtual machine, ~ 16MB, stored on an IronKey). Built
from source, reasonably tamper-proof, works offline, encrypted at rest. It's a
bit of pain to remember to reset the time/date every time I boot it, but it
works quite well.

Sadly you'll spend the rest of your time installing your root certificates in
everything (good luck with mobile devices, I have torn my hair out in the past
with Sony-Ericsson; Oh, you have to drag the specially-named-file-in exactly-
the-right-encoding onto the HIDDEN node in the PC-suite-file-explorer-horror-
window, of course. HOW OBVIOUS.)

~~~
gravitronic
Can you elaborate why you've spent the considerable time to do this? Do you
habitually travel / connect to completely nefarious networks?

~~~
jrabone
Much for the same reasons I run my own mail server - because I can, I learned
something doing it, it gives me more control than I'd otherwise have. I also
don't trust any network with plain-text credentials so TLS was a requirement
for mobile email.

IronKey was something I already used, so it was natural to try and build a
minimal CA that fit on it.

Given the choice I'd prefer a good VPN solution but the aforementioned pre-
smartphones simply couldn't do that and SSL VPNs weren't common, so TLS was
what we had. Now, that little CA primarily gets used for generating Xauth-RSA
certificates for my IPSEC VPNs...

~~~
newman314
Any chance you could release a scrubbed setup or a blog post?

I'm looking at doing this and rather not have to slog through the nuances if
possible. (I deal with certain on a sufficiently infrequent basis that I have
to actively try to figure the steps again. One of the frustrating things of
having to deal with cryptic options)

------
rdl
I'm a bit confused why they didn't remove TURKTRUST entirely. It's pretty
obvious that they issued to a government under some kind of incentive or
coercion, and thus became a MITM threat.

I'm sure every reasonably sized government already has either a root key or an
intermediate key, but there should at least be enough penalty when you get
caught publicly to deter it -- at least raise the cost of being caught enough
that governments won't use their CA powers without fear they might be putting
the capability at risk each time.

~~~
ajross
Obviously they don't blacklist the CA because doing so would break the sites
of all of their customers. That's a very high-cost action, and the cost is
borne by people not involved in the security situation. You do it only in an
emergency. The system has an existing mechanism in place: revoke the cert,
(though see the post by mrb above which argues that the revocation was done
incorrectly).

Longer term, yes: I think looking at punishing TURKTRUST in some way,
including revoking their CA, makes sense.

~~~
mseebach
But isn't this exactly a high cost situation? Send a loud and clear message
that CAs are entrusted with an enormous level of trust, and they damn well
better make sure that their procedures are water tight, at the risk of losing
their business overnight.

~~~
MichaelGG
Punishing CAs is a laudable goal, but just immediately revoking a CA will
result in worse security.

If TURKTRUST is immediately revoked, then all existing sites using it are
toast, _despite them not being compromised_. That just tells users that SSL
errors are not to be trusted, that you should just click through.

Hopefully, they remove TURKTRUST from signing future certificates. That way
existing customers continue to work, but they can't do more damage, and the
lesson is taught. Although, I don't think that's built-in to the cert system,
it'd be a decent addition.

~~~
mseebach
They could give them one month or even three months so their client have time
to get their certs replaced, that's not terribly important. But in a broader
sense, yes, they were compromised - they had an entity vouch for them that
apparently vouched with a blank cheque.

------
dchest
A bit more details from Microsoft:

    
    
      "TURKTRUST Inc. incorrectly created two subsidiary Certificate Authorities: 
      (*.EGO.GOV.TR and e-islam.kktcmerkezbankasi.org). 
      The *.EGO.GOV.TR subsidiary CA was then used to issue a
      fraudulent digital certificate to *.google.com."
    

[http://blogs.technet.com/b/msrc/archive/2013/01/03/security-...](http://blogs.technet.com/b/msrc/archive/2013/01/03/security-
advisory-2798897-released-certificate-trust-list-updated.aspx)

------
aaronharnly
How am I supposed to trust an official Google security blog named
"googleonlinesecurity.blogspot.com"? What a bizarre place to put your security
blog!

~~~
kefs
What were you expecting.. wordpress?

Here is Google's blog directory.. all on blogspot, their blogging platform:

[https://www.google.com/intl/en/press/blog-
directory.html#tab...](https://www.google.com/intl/en/press/blog-
directory.html#tab0)

~~~
jzwinck
I would have expected something like security.google.com, which would be
pretty obviously not a hoax. As it stands, what stops anyone from making
googleinternetsecurity.blogspot.com?

~~~
aaronharnly
Indeed. I went ahead and created <http://googleinternetsecurity.blogspot.com>
as a proof of concept. I wonder whether it will be allowed to exist.

------
RyanZAG
Sounds like only Chrome has been updated to reflect this? Which means all
Android/iOS apps that rely on a secure channel to a *.google.com domain can be
MITMed?

If so, then current SSL should be regarded as 'broken' effective immediately
and not used for secure transactions with Google (and probably anybody else).

~~~
cleverjake
I would assume the cert was revoked, this is about how they do not trust any
cert signed by the same authority.

~~~
lmz
Even if the certificate was revoked, how do the Android devices know that the
certificate was revoked? Do they regularly update CRLs or do they check using
an online protocol e.g. OCSP?

------
Nux
The CA system is fscked beyond repair (it always has been). We need an
alternative now.

~~~
loungin
Do you know of any alternatives being worked on? No snark intended, I am
genuinely curious about the current state of affairs.

~~~
jcase
Some developments in this area are:

* Convergence.io

* DNS-based Authentication of Named Entities (DANE) + DNSSEC

* Tack.io

For various reasons listed in [1] Convergence is not likely to be implemented
(by default) in major browsers.

On DANE + DNSSEC, where the cert is authenticated via the information
published in your DNS, Moxie Marlinspike has said it better then I can:

    
    
        "CAs are sketchy, but this is a whole new world of sketchiness. Think,
        sketchasaurus. Registrars were never built or selected with security in mind,
        and most of them don’t have a very good track record in this area. Shouldn’t it
        be laughable that the current first step in deploying DNSSEC is to create an
        account with GoDaddy?"[2]
    

The 2011 BlackHat video[3] and blog post[2] by Moxie Marlinspike are great
sources of information.

IMO, Tack.io is the most viable solution. It's compatible with the current
model but removes the thread of one CA being able to compromise all domains.

[1] <http://www.imperialviolet.org/2011/09/07/convergence.html>

[2] [http://www.thoughtcrime.org/blog/ssl-and-the-future-of-
authe...](http://www.thoughtcrime.org/blog/ssl-and-the-future-of-
authenticity/)

[3] <http://www.youtube.com/watch?v=Z7Wl2FW2TcA>

~~~
richardwhiuk
Registrar's are trusted. They can change the DNS records for your domain to
point at their servers, allowing them to intercept email. That's sufficient to
allow them to get certificates issued for your domain through some providers.

~~~
jcase
For domain validated certs, certainly.

The issue is that it doesn't solve anything. We merely shift (more)
responsibility to registrars and NICs. You can change (untrust) registrars I
suppose but if you have a .com you'll have to trust Verisign _forever_. Well,
at least as long as they operate the .com tld. So if Verisign loses your
trust, there is even less you can do than today.

------
erydo
This is something I was thinking about last night, prompted by the recent
resurgence in awareness of government wiretapping and some of the responses of
"use SSL everywhere so it's not a problem."

Does anything prevent a government from privately coercing a CA into issuing
certificates that enable a MITM attack?

It may be that the difficulty of getting a gag order for a CA could be greater
than the difficulty of obtaining a warrant on the destination, unless the
destination is foreign--but it still sounds feasible for a government to do.

Am I off base about that?

~~~
tptacek
That's becoming a high-risk proposition now that Chrome (and apparently
Firefox) are pinning certs. A government could indeed coerce a CA into issuing
certificates, but they can't easily coerce Google into transparently
overriding their pinned certificates, and when the two disagree, the world can
see which CA root chain was used to forge the certs.

As you can see, it doesn't even take pervasive deployment of a technology like
TACK to significantly mitigate the threat of rogue CAs.

------
mixedbit
I wonder if EFF SSL Observatory detected anything suspicious about the phony
certificates.

~~~
schoen
Not in advance, but it will be interesting to see whether we have observations
of them.

We (and other people who care about certs) could probably use contributions of
algorithms for detecting things that are suspicious about certificates. :-)

One thing that I believe is not yet implemented but that I should try to
implement is finding observations in the Observatory that, if they had been
made by Chromium, would have violated a cert pin in Chromium. (Most of the
observations in the Observatory are made by Firefox users, so their browsers
wouldn't notice a pin violation at the time the observation was made.)

Another thing that could be interesting is finding all apparently valid certs
that have never been seen by any Perspectives notary.

Anyway, there are a lot of queries to be run!

------
biturd
Does anyone know how to remove turntrust as a CA in Mac OS X? Or better,
disable them? If I go to their website I can click on the little lock which
shows they are valid.

I look in the keychain, and I see three listings for TURKTRUST and it looks
like the only option is to delete them. I can't set the cert to alert or warn,
which is what I would prefer rather than just fully revoke them at this time.

~~~
reaperhulk
Double click the cert, then click the disclosure triangle next to trust. You
can then select never trust for a variety of different purposes. Screenshot:
<http://d.pr/i/c8Tx>

~~~
biturd
Thank you. I tried that but mine had no triangles. I closed and reopened the
app and then they showed up. I must have hit a quick UI glitch or something,
but a relaunch solved it. Thanks again.

------
biturd
Why does this happen? It seems technically solvable. If you want a cert, you
have to prove you own that domain. No amount if faxing or email is going to
truly prove that.

And Chrome hasn't asked me to update, am I safe or do these updates happen
unbeknownst to me server side?

If people can lie, they will, and there will be security issues. In this case
a wildcard got out for *.google.com! MITM all google.com email, sounds fun!

Correct me if I'm wrong, but there isn't a single google webmaster tools or
analytics account out there connected to the wrong domain. Why? Because to
engage those services you must own the domain and have access to it.

Google makes you put an HTML file they generate in root or add a meta tag.
They then request that URL and look for the resource.

If you want an SSL cert, you should have to put a file at example.com/ssl.html

Wildcard SSL's are trickier. My previous SSL provider charged over 100.00 per
cert and that was as a reseller. They wouldn't even offer wildcards in the
beginning. I believe they do now but it's a significant application process.

You still could require the placement of a file but that doesn't entirely
prove they should get a wild cert for the domain. It still seems better than
nothing and would have stopped the issuing of this particular cert.

Not to mention, wouldn't you think every CA or intermediate has a blacklist if
domains they simply don't provide certain for? Google, Facebook, twitter,
LinkedIn, every major ISP, etc.

Or what about using DNS as a means of authentication. If you want an SSL cert
you have to add a TXT record of ssl. TXT (value issuer provides). Again, in
this case, they would have failed the ability to interact with google DNS and
no matter what DNS server they asked would tell the same.

They could set up a phony DNS server, but the issuer has no reason or
knowledge to follow that out of band chain. Then the only way is a rogue
employee, which is something no technology is going to solve and probably will
remain a risk of all business security from SSL certain to banks to brick and
mortar inventory shrink.

All these methods are fully automatic and should be of little burden to the
registrar to implement. It's not like they have to handle a million requests a
day. A page that spits out a hash of the domain and curl's the resource could
probably handle most registrars load.

~~~
enneff
Prove to whom? The people that issued this cert were effectively (albeit
mistakenly) a certificate authority. They could issue whatever certs they
liked.

------
chayesfss
pki in it's current form is broken which is why a lot of enterprise customers
use SecureAuth (whom I work for) which prevents any type of mitm attacks, even
on mobile deviecs

