
Turkish government agency spoofed Google certificate “accidentally” - 6thSigma
http://arstechnica.com/security/2013/01/turkish-government-agency-spoofed-google-certificate-accidentally/
======
sc68cal
In previous instances (like Comodo), I can recall discussions on the Mozilla
mailing lists about the so called "death penalty" of revocation for CAs who
have demonstrated serious lapses.

I think this situation is even worse. Forgive me for sounding paranoid but
this sounds like collusion between the government of Turkey and Turktrust, to
intercept communications. I believe that the harshest penalty should be
pursued, which is removal of the Turktrust root certificate from all trust
databases. They cannot be trusted.

EDIT:

It appears that Mozilla is on the same page as I am.

[https://blog.mozilla.org/security/2013/01/03/revoking-
trust-...](https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-
turktrust-certficates/)

[https://groups.google.com/forum/?fromgroups=#!topic/mozilla....](https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/aqn0Zm-
KxQ0)

Another good idea mentioned on the mailing list was to blacklist the auditor:

[https://groups.google.com/d/msg/mozilla.dev.security.policy/...](https://groups.google.com/d/msg/mozilla.dev.security.policy/aqn0Zm-
KxQ0/OOMOOFBKXoAJ)

~~~
cheald
I'd agree. We have plenty of CAs - killing a few off here and there isn't
going to harm our ability to manage certificates, and those that make these
kinds of mistakes - intentionally or otherwise - aren't worth the trouble of
having them around.

A couple of CAs being revoked for slipping the wrong certs to the wrong
parties is only going to make other CAs triple check their work before handing
out the keys to the kingdom.

~~~
tptacek
No, it won't harm our ability to manage certificates. What it will do instead
is create a point in time where suddenly a whole mess of websites that used to
be protected with HTTPS are now no longer protected with HTTPS. If there's a
graceful and safe way to provide effective advance notice for this, I haven't
heard it yet.

I agree in spirit; I'd like to see more CA's get the death penalty. But the
pragmatic argument against it is convincing.

~~~
sc68cal
While I agree with you about pulling the rug out from users - if the CA is
already forging certificates for important domains, then how much security do
they really have?

~~~
dustingetz
right now only the turkish government can do MITM - other parties can't.

~~~
jacquesm
> right now only the turkish government can do MITM - other parties can't.

First, if true that's a small comfort. Second, how do you know that is true?

~~~
danielweber
It's in the Turkish government's to use these invalid certs as little as
possible, so they are probably going to use them against people like Turkish
dissidents.

(I don't mean to dismiss their interests, but they are distinct from other
people's interests.)

------
tptacek
I believe them. If you're going to use a malicious certificate to spoof
traffic, you'd be pretty dumb to start by targeting Google, since all their
properties are pinned in Chrome. You'll just get caught.

Also, using X.509 CA=YES certificates to mint new certificates on the fly is a
standard and legitimate feature of corporate network hardware. In virtually
every large enterprise network, employees don't have direct access to the
Internet; they bounce through proxy servers. The middleboxes that make this
work all have "upload a root CA cert here" features to make this work.

That they accidentally issued a malicious certificate, I think, makes things a
little worse from my vantage point. There are a million ways to get hacked,
but not as many excuses for just being sloppy.

~~~
revelation
I'm fairly confused by your stance here. I was expecting you to tell us that
a) security with backdoors is worthless (intermediate CAs, for use in packet
inspection devices, not merely proxies) and b) security without control (and
repercussions) for those that guarantee the security.

It's not exactly a "standard and legitimate feature" either; there were
lengthy discussions this very year [1].

[1]: <https://bugzilla.mozilla.org/show_bug.cgi?id=724929>

~~~
tptacek
You're confusing two issues. Enterprises can MITM traffic without being issued
an intermediate CA=YES certificate; they just add their own root certificate
to all their desktops.

~~~
GauntletWizard
Enterprises MITMing traffic is wrong, regardless of any of this; It's pretty
much the reason why Google has introduced Cert Pinning, as the 'security'
aspect of those boxes is utter and complete bullshit.

~~~
deadbea7
I can think of legitimate reasons for enterprises to MITM traffic. For
example, protecting users against malware as a result of drive-by downloads or
spear phishing campaigns. Data loss prevention is another good reason -- I
would want an enterprise that I'm trusting with my credit card data to alert
on payment instruments leaving their network to gmail accounts, for instance.

~~~
rmc
_Data loss prevention is another good reason_

In some regions, companies are legally required to ensure personal data is
protected. It's against the law for them to not protect it.

------
rdl
Only somewhat joking: maybe there should be a rule that CAs are only allowed
to issue to entities in foreign countries, outside traditional alliances, to
ensure independence. I'm pretty confident Iranian intelligence couldn't
pressure a major US CA to issue a cert for Iranian intelligence gathering; I'm
pretty confident Turkish intelligence couldn't pressure a Japanese CA to issue
for intelligence purposes. The problem is then US sites would need to get
their certs from (at best) Russian or maybe Chinese CAs, and possibly only
North Korean CAs.

This still doesn't prevent the "evil CA issues something covertly to do evil",
but it at least leaves an audit trail in that legit, widely-used certs aren't
likely to be issued to illegitimate parties.

~~~
alanctgardner2
The problems are mostly in business administration. A Japanese CA would need
staff who can communicate in every foreign language that could be encountered
in a 'hostile' nation. And they'd presumably have to get those employees from
the Japanese population, because otherwise if you hire all Turkisk nationals
at a Japanese CA, what's the point? Then they'd have to be willing to accept
payment in the currency of all the hostile nations, etc.

Not to mention the difficulties of defining hostile nations. That would just
further encourage countries like China and the US, which both want to
intercept traffic, to negotiate with each other to get mutual access.

------
enraged_camel
It's worth noting that Turktrust is not a government agency, and ego.gov.tr is
simply the website of the municipal department that controls traffic and
public transportation in the capitol city of Ankara. The likelihood that they
would use these certificates for malicious purposes is virtually zero.

~~~
michaelt
I'm not an expert on how spy agencies operate, but if they were buying a
certificate like this to spy on people I don't think they'd ask to have their
own name put on it?

Turkey often blocks websites [1] so they obviously have a problem with some of
Google's operations, and have the capability to mess with regular citizens'
internet connections.

[1] [http://www.edri.org/edrigram/number10.24/ecthr-google-
blocki...](http://www.edri.org/edrigram/number10.24/ecthr-google-blocking-
decision-foe) <http://www.bbc.co.uk/news/technology-11659816>

------
meaty
Doesn't surprise me.

Even if it was an accident, it's improbable.

Then again, back in the dark ages, we found that if NT3.51 was under heavy
load, it was possible to generate two identical guids in under 2 hours of wall
time.

~~~
GIFtheory
It's also worth noting that Turkey's government routinely blocks Google
services (especially youtube) for hosting "offensive" content (e.g.:
[http://www.huffingtonpost.com/2010/06/08/turkey-blocks-
googl...](http://www.huffingtonpost.com/2010/06/08/turkey-blocks-google-
serv_n_604148.html)). So, a sinister explanation is even less far-fetched for
Turkey in particular.

------
biturd
Why are there intermediary CA's? They seem to hold the same power as a CA but
little of the responsibility.

It would be similar to allowing a secondary DNS provider to hold primary
powers. I could start big-huge-secondary-dns-provider.example.com and edit my
zones locally. The master could pick them up, and serve them out.

DNS was not made that way, so why is the chain of command in a CA made that
way?

* I understand you can edit a secondary and if people are using it as a recursive DNS provider, you will in fact get back "lame" data, but that is almost never the case where a secondary is used as recessive recursive. At least not in any of the setups I have seen, deployed, or administered. [edit: spelling]

------
alpb
Wrong, it is not a government agency. It is privately held and run as CA with
the permission given by the government.

~~~
geofft
Read the article (or any of the other ones). TURKTRUST did not spoof the
_.google.com certificate. They accidentally issued an intermediate (chained
CA) certificate to a user, who happened to be a government agency, and that
user accidentally spoofed_.google.com.

~~~
alpb
Title says government agency did, not the user. The problem is with the title.

~~~
pyre
Re-read that sentence. The government agency is the _user_ in this case, _not_
the CA.

    
    
      | TURKTRUST [a private company] did not spoof the    
      | .google.com certificate. They accidentally issued
      | an intermediate (chained CA) certificate to a user
      | [a government agency], who happened to be a
      | government agency, and that user [a government
      | agency] accidentally spoofed
      | .google.com.

------
ekurutepe
It might be plausible that the CA issued the subsidiary CA cert to a
government agency due to incompetency, it is very hard to chalk it up to a
'mistake', if that said government agency uses the accidentally issued CA cert
on their SSL intercepting firewall. What a convenient accident...

------
alanctgardner2
I like TACK as a technical solution to this problem, but there is also the
possibility of improved regulatory oversight. My question is why there isn't a
stronger, official governing body for inclusion of certs in browsers. Right
now it looks like MS, Mozilla and Google are the de facto deciders of whose
certificates can be bundled by default in a browser. This basically decides
who can be a root CA. The problem is, as three un-coordinated entities with no
formal relationship, they have no procedure for putting the toothpaste back in
the tube - they can't revoke a certificate, because there's no procedure.

Personally, I would promote the creation of a separate body for managing root
CA certificates, in which any browser vendor could participate. Members would
agree to bundle only the certs approved by the body. The body would collect
from participating CAs a certain portion of the monies paid for certificates -
somewhere between 25% and 50%, to be released when the certificate expires.
This serves as a sort of escrow for services rendered - customers can be
confident they will get n years of use out of a certificate, even if the CA
vanishes. Top level CAs would be responsible for remitting payments from
intermediates they authorized. This would form a fund to facilitate the
movement of customers, in the event a CA became illiquid or was deauthorized -
sort of an FDIC for SSL certs.

If a breach of trust occurred, or a CA went bankrupt, had its assets seized by
a corrupt government, etc. this body would have the authority to blacklist the
CAs certs after a window - 30 to 60 days. They would notify all of the CA's
customers that they were being issued new, free certificates from a still-
authorized CA of their choosing, with the payment for the new CA to be issued
( at a lower than market, but not insubstantial ) from the depository
insurance fund. The body would provide customers with a list of approved CAs
by country, and while the remitting process would likely be a nightmare the
first time, at least people would have a timely way to get new, valid certs.
Customers would complain a bit about the work to deploy new certs, but that's
the cost of running (actually) secure infrastructure.

This would achieve a few goals: \- browsers would be obligated to bundle a
common set of certs, with a common approval and audit process. This should be
less work for new CAs to get approved \- CAs would have a financial incentive
to stay secure - a breach means we can legitimately revoke your authority, and
you no longer own the cash we held in escrow \- browsers would have teeth to
create a 'death penalty' like Mozilla proposes, and better yet, they would all
have the same criteria \- certificate owners would be less conflicted between
user security and their financial interests - the escrow would reduce their
losses if a CA became insolvent

