Turkish government agency spoofed Google certificate “accidentally” | Hacker News Reader

Turkish government agency spoofed Google certificate “accidentally”

arstechnica.com

104 points6thSigma63 comments

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://groups.google.com/forum/?fromgroups=#!topic/mozilla....

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

https://groups.google.com/d/msg/mozilla.dev.security.policy/...

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.

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.

This seems like a problem that could be pretty easily solved by the browser vendors, similar to how they do malware checks. Throw up a "this site's security certificate was issued by a compromised authority, and will no longer be valid in <x time at y date>. If this is your website, click here for more information." Run that for a sufficiently long period of time, then kill the CA.

It's not perfect, but we have a huge web of people using these affected sites on a daily basis who can serve as a very powerful driving force to spur change when necessary to minimize fallout.

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?

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

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

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

More than they do if the whole CA is removed. Sorry, annoying but true. Promote TACK!

As a future mitigation strategy, what about encouraging website owners to have certificates independently signed by multiple CAs? Perhaps require multiple CAs for EV certs, and maybe for certain HSTS sites?

This makes it easier to revoke a bad CA and harder to spoof a high-value certificate, and _also_ gives the CAs more revenue, which sounds like a win-win situation for everyone. :-)

Because that is more effort for much less benefit than TACK.

TACK only helps with clients that have seen a site before, right?

Yes, but that's most sites.

This leaves an attack vector against people doing first-time-ever connections (like fresh installs of new OSes that are grabbing their new security packages), but TACK pins can also be pre-loaded or shared between clients for those circumstances.

Chrome could warn "XYZ CA is scheduled to be marked untrusted in 30 days". The sites large enough to have economic impact if they were unsecured would notice and scramble to get new certs. Other browser vendors would follow. A warning shot is fired paving a path for harsher penalties in the future.

I'd argue that as long as an intermediate is passing out BS certs, nobody (modulo cert pinning etc) who trusts that intermediate or its root is truly protected.

I don't quite understand the "no longer protected with HTTPS." If their certificates stop working as part of the CA's revocation, then they'll have to get new ones before they can continue operating over HTTPS, of course. But they won't somehow automatically revert back to HTTP or anything, they just won't be able to carry on business (or at least their users will have to click through scary warnings). So they'll be offline for, what, a few hours, days at most, while they get this sorted out? And never actually insecure, just inaccessible.

HTTPS without a verified certificate (ie, after clicking through the warning) is only cosmetically more secure than HTTP.

This is kind of funny. The connection is still encrypted from others that might see it in-flight (ie, coffee shop, etc). However, your right, you would not be able to verify that the person on the other end was really the one you wanted to. However, this discussion is here because someone had one that WAS perfectly valid for gmail.com, even if it was not actually owned by google.

Yes, but in the current situation only a small subset of people were exposed to that certificate, whereas killing the CA outright exposes everyone to bogus certificates for the CA's domain.

The connection is still encrypted from others that might see it in-flight (ie, coffee shop, etc)

Not really. If you were using your laptop on wifi in a coffee shop, I could intercept your traffic and rewrap the SSL in my SSL. You then have no way to know if you're securely talking to me, or to the original site.

Wouldn't you get a "certificate revocation" banner of some kind though, as apposed to "certificate unknown"?

edit: read the update at the top of the linked article, which clarified that it is not just revocation, but also the inclusion of a new root cert for turktrust that has been suspended.

Isn't HTTPS relying on a demonstrably insecure CA also only cosmetically more secure than HTTP?

It depends who has access to compromise the CA. If it was the Turkish government that did so, they probably aren't going to waste their ammo to try to decrypt Joe Random's banking information.

You can MITM any HTTPS site in the world with an invalid certificate right now. Killing this CA won't change anything in that respect, so I still don't understand what you're getting at, or how killing this CA would make some sites less secure for a period.

All of the sites with legitimate Turktrust certificates would suddenly have invalid certificates. That's all I'm saying.

If you are operating under the assumption that Turktrust is head-to-tail untrustworthy and actively subverting the HTTPS/TLS PKI, then sure, that doesn't matter.

You said "no longer protected" which is what I'm trying to understand. All of those sites would suddenly have invalid certificates, sure, until they fixed it. But the interim period where they have invalid certificates is no more dangerous or insecure than the period before or after. The sites become less accessible, but they remain equally safe (or unsafe).

The CA itself wasn't demonstrably compromised. They issued intermediate CA certs, which makes them untrustworthy as someone who holds the power to issue intermediate CA certs, but doesn't necessarily undermine the trustworthiness of certificates issued through them directly (rather than through their bad intermediate certs), as their bad certs are not part of the chain of trust for end-user certs issued directly through them.

I think a known subset of websites having their HTTPS broken as a result of their CA misbehaving is much more preferable to a single CA having effectively broken all HTTPS for all internet users since 2011.

It's not a clear dichtomy, though: harsh penalties rarely alter behaviours.

I don't think you are paranoid.

They went from a "mistake" in issuing a "testing" certificate that managed to propagate through their system that just "happened" to be sitting around and configured in a way to be ready to execute a MITM configuration. To me, the chances of that happening seem challenging at best. To have it happen automatically and without hitch or fail, seems highly improbable.

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.

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

The distinction is presumably about whether clients have to be modified to accept a particular (organizational) root or whether someone gets access to a root CA that will work with unmodified mainstream browsers.

The "standard" way of doing enterprise network surveillance and censorship is by getting end-users to use client software with a modified configuration that (unlike the general public's browsers) accepts the surveillance and censorship without generating a browser warning. In the Trustwave case, it was done with unmodified software and hence could have been done against the general public, or unsuspecting corporate users.

There have been interesting policy discussions about the fact that HTTPS site operators may not "consent" to this surveillance, even if some end users are considered to have done so. For example, PayPal might not want corporate network operators to have access to employees' PayPal credentials or financial transaction data. Hence PayPal's preferences might be something like

employee doesn't use PayPal at work > employee uses PayPal at work without interception by employer > employee uses PayPal at work with interception by employer

while the employee's preferences might be

employee uses PayPal at work without interception by employer > employee uses PayPal at work with interception by employer > employee doesn't use PayPal at work

and the employer's preferences might be

employee doesn't use PayPal at work > employee uses PayPal at work with interception by employer > employee uses PayPal at work without interception by employer

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.

So, presumably they put their badly-issued "real" public cert on the checkpoint (instead of making their own captive CA and root key/cert for that), and it would have just complained/not worked, normally, but since it was mistakenly issued as CA=YES, it worked, and no one cared. Then Google discovered it because of some Chrome users behind the checkpoint.

I guess incompetence is a decent explanation here, and probably the most likely, but also provides a very convenient explanation if you wanted to hide something more sinister.

"Then Google discovered it because of some Chrome users behind the checkpoint."

And cue the banning of Chrome on government networks in 3. 2. 1...

I hope they wouldn't. It's like a canary in the coal mines. It's an easy way to be alerted to serious problems in your organisation....

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.

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.

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.

Employers often have legal responsibilites to their employees to ensure that those employees aren't exposed to ahem unprofessional content from other employees. The only real way to do this is to intercept and filter HTTPS traffic. Otherwise you're one HTTPS porn site away from a sexual harassment case.

That's pretty silly. Enterprises are also obligated to ensure that random employees don't spirit out millions of customer account files over the Internet. If you want an unimpeded Internet connection, provide your own.

Chrome will ignore the pin if there's manually installed CA on the client, exactly to allow corporate MITMing.

The goal might be to target google and specifically gmail. They might have wanted to wiretap gmail conversations.

The Islamic fundamentalist fethullah gulen gang is a secret organization that has taken over most important positions in Turkish police and courts. They are wiretapping anybody they want using police resources. They blackmail, imprison and silence secular opposition. For example, they currently keep over 70 journalists in prison because of what they said or wrote.

My point about Gmail is that it is uniquely difficult and risky to spoof, because Chrome has Google's real certificates pinned.

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.

I was thinking this for few months.

Many companies nowerdays are registered in tax havens. Wouldn't US CAs just get registered as Cayman Islands CAs?

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.

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.

It's a fraudulent certificate; why should we believe anything in it?

Turktrust is part of "Hant-to-hand With Turkish Military Force" and EGO operates Electricity-Gas-otoBus in the capital city, Ankara.

Why ego.gov.tr would need to have a certificate with *.google.com? I don't see any legitimate use case...

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.bbc.co.uk/news/technology-11659816

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.

It is probable. Just the probability is low. But it could happen.

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...). So, a sinister explanation is even less far-fetched for Turkey in particular.

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]

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

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.

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

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.

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

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

Reply on news.ycombinator.com