Enhancing digital certificate security (Fake *.Google.com cert issued)(googleonlinesecurity.blogspot.com)
googleonlinesecurity.blogspot.com
Enhancing digital certificate security (Fake *.Google.com cert issued)
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
13 comments
"I, 'J. Random techie', on behalf of the internet community, hereby thank you for your hard work on forward-looking protocols, prototypes and public education around these issues Moxie. Much appreciated." Round of applause.
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?
Presumably it still checks the certificate is valid otherwise the worse case would just be that the legitimate site would not work.
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.
Sadly, apparently not supported in IE yet.
"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:
[1] http://www.turktrust.com.tr/sil/TURKTRUST_Kok_SIL_s3.crl
[2] http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_s3.c...
[3] http://www.turktrust.com.tr/sertifikalar/19_TURKTRUST_Elektr...
[4] http://www.turktrust.com.tr/sertifikalar/20_TURKTRUST_Niteli...
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
[1] http://www.turktrust.com.tr/sil/TURKTRUST_Kok_SIL_s3.crl
[2] http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_s3.c...
[3] http://www.turktrust.com.tr/sertifikalar/19_TURKTRUST_Elektr...
[4] http://www.turktrust.com.tr/sertifikalar/20_TURKTRUST_Niteli...
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...
[1] http://events.ccc.de/congress/2012/Fahrplan/events/5319.en.h...
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.
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.
> 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.
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.
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.)
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.)
Can you elaborate why you've spent the considerable time to do this? Do you habitually travel / connect to completely nefarious networks?
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...
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...
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)
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)
neat, thanks for the followup!
Actually, I've thought about starting a "real" CA (read: get certified etc). I'm not sure the world needs another one though.
Your experience running a homebrew setup is exactly why I think CAs will continue to exist—even if self-signed certs would be widely supported via DANE. I doubt many businesses are going to run their own CA in order to save < $1000 a year.
Your experience running a homebrew setup is exactly why I think CAs will continue to exist—even if self-signed certs would be widely supported via DANE. I doubt many businesses are going to run their own CA in order to save < $1000 a year.
So did Honest Achmed, but he got shut down. https://bugzil.la/647959
The technical reason you can't issue certificates by having one for the parent domain is because the certificate system, for some reason, has no notion of restricted scope for CAs, as far as names go. So there's no way to say that a certain CA can sign for only these names - it's all or nothing.
This is not technically true. X509 contains a provision called name constraints which provides this exact feature, but since no client has ever implemented it in practice you are correct. (There are probably a few clients out there implementing and abiding by name constraints, but they are in the decided minority)
Internet Explorer, Mozilla Firefox, and Google Chrome all respect name constraints. I believe Opera does as well.
The issue is that according to RFC5280, nameConstraints MUST be marked critical, which would break all clients that don't support nameConstraints - including Apple OS X and iOS. As a result of not wanting to break these clients, no CA has practically deployed nameConstraints.
However, as is being discussed in the CA/Browser Forum AND Mozilla's security policy list (and previously, within PKIX), CAs and browsers are considering diverging from 5280, and not REQUIRING that 5280 be marked critical. ( https://groups.google.com/forum/?fromgroups#!topic/mozilla.d... for more context)
This will allow a transition period, where CAs that would otherwise NOT include nameConstraints (because it would break clients) can now safely include nameConstraints and not break the legacy or insecure clients that do not support them. Mozilla's proposed CA Certificate Inclusion Policy ( http://www.mozilla.org/projects/security/certs/policy/WorkIn... ) would REQUIRE that CAs use name constraints when issuing sub-CAs that are not audited, secured, and conformant with Mozilla's policy.
The issue is that according to RFC5280, nameConstraints MUST be marked critical, which would break all clients that don't support nameConstraints - including Apple OS X and iOS. As a result of not wanting to break these clients, no CA has practically deployed nameConstraints.
However, as is being discussed in the CA/Browser Forum AND Mozilla's security policy list (and previously, within PKIX), CAs and browsers are considering diverging from 5280, and not REQUIRING that 5280 be marked critical. ( https://groups.google.com/forum/?fromgroups#!topic/mozilla.d... for more context)
This will allow a transition period, where CAs that would otherwise NOT include nameConstraints (because it would break clients) can now safely include nameConstraints and not break the legacy or insecure clients that do not support them. Mozilla's proposed CA Certificate Inclusion Policy ( http://www.mozilla.org/projects/security/certs/policy/WorkIn... ) would REQUIRE that CAs use name constraints when issuing sub-CAs that are not audited, secured, and conformant with Mozilla's policy.
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.
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.
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.
Longer term, yes: I think looking at punishing TURKTRUST in some way, including revoking their CA, makes sense.
Mozilla removed the CA, rather than just blacklisting the intermediate certificates: https://blog.mozilla.org/security/2013/01/03/revoking-trust-...
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.
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.
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.
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.
If the CA issues certs like that they actually are compromised.
Maybe "cost" is the wrong metric to argue about. My point was that we have a situation where a bad cert was issued, and the correct treatment for it, barring special circumstance, is to use the process designed to revoke bad certs.
CA death penalty for someone like TURKTRUST matters to users a lot less than CA death penalty for a global CA like Verisign or Entrust. I'd rather get the policy demonstrated with a regional CA (or ideally a small/enterprise CA) and made clear enough to make all other CAs suitably cautious.
that logic is always going to apply , meaning effectively, you are never going to be able to remove their CA cert, because its always going to break their customer's sites. So no matter how glaring the security problems a CA is never getting delisted. The PKI model as it exists is broken beyond repair.
https://bugzilla.mozilla.org/show_bug.cgi?id=647959
https://bugzilla.mozilla.org/show_bug.cgi?id=647959
No, Diginotar had their CA removed from several browsers and went bust https://en.wikipedia.org/wiki/DigiNotar
We need a solution to this. It comes up every time a ca misbehaves.
How hard would it be to allow a website to have multiple certs? If Turktrust's important customers had redundancy, we could pull less painfully.
Or for less rollout, could browsers acknowledge turktrust only as a root for .tr hosts? That would contain the damage, but probably not hit many legitimate customers.
How hard would it be to allow a website to have multiple certs? If Turktrust's important customers had redundancy, we could pull less painfully.
Or for less rollout, could browsers acknowledge turktrust only as a root for .tr hosts? That would contain the damage, but probably not hit many legitimate customers.
Then you would just have two attack vectors; compromise either of the private keys and you can be the MITM.
You could use the same key and just submit multiple reqs to different CAs. This wouldn't be any worse than having one, and would be a way to have a "backup cert" in case a CA screws up.
Considering the private keys are probably stored in the same place, I wouldn't consider it an additional attack vector.
You can already MITM if you compromise any CA's private key.
I'm afraid that was my response. I doubt I'll need them, and I'll re-evaluate if I ever do, but as far as I'm concerned TurkTrust is not a valid CA. Here's how on Windows (you can't delete them, they come back with the next CA update):
IE, Chrome & everything else that uses the OS:
IE, Chrome & everything else that uses the OS:
runas /user:Administrator "mmc certmgr.msc"
(might also work as another Admin user if you disabled the real Administrator account)
Expand "Trusted Root Certification Authorities"
Double-click on TURKTRUST certificate
Click "Details" tab and "Edit Properties..." button
Click "Disable all purposes for this certificate"
Repeat for each TURKTRUST certificate in turn
Click "Options" -> "Advanced" and choose the "Encryption" tab
Click "View Certificates" button
Choose "Authorities" tab
Click on each TURKTRUST certificate in turn and press "Delete or Distrust"...
Isn't Turkey west enough for you ...
Or a great west wall should build. ??
Eh, "western world" is a nebulous term. For example, most people would implicitly refer to Australia as a western country, despite geographically being about as east as Japan (a fully industrialized and modern society).
From my relatively uninformed perspective, I would say that Turkey kind of straddles the line between east and west. They are not a primarily English speaking country, they are not (yet?) in the EU nor would I normally think of them as particularly "Europey" (as I would Switzerland; "Europey" is probably just a measure of how "western Europe" a country is.).
My perspective is probably being influenced by history quite a bit as well: http://en.wikipedia.org/wiki/File:Theodosius_I%27s_empire.pn...
From my relatively uninformed perspective, I would say that Turkey kind of straddles the line between east and west. They are not a primarily English speaking country, they are not (yet?) in the EU nor would I normally think of them as particularly "Europey" (as I would Switzerland; "Europey" is probably just a measure of how "western Europe" a country is.).
My perspective is probably being influenced by history quite a bit as well: http://en.wikipedia.org/wiki/File:Theodosius_I%27s_empire.pn...
Having just moved from Britain to Singapore, I can tell you that for the people here, Turkey looks very much like a part of Europe.
It's not whether I think Turkey is "West" or "East", it's more than I just don't interact with Turkish websites - so why should I broaden the attack surface of my browser unnecessarily? I realise that the CA -> domain mapping is a poor approximation, but it's the best we've got.
I have a feeling that _firatto is Turkish ("Firat" is a common Turkish name - I know because I'm Turkish!) so he may have taken offense to what you inadvertently implied about Turkey not being part of "The West". :)
Thanks for sharing how to do this on desktops.
My frustration is with mobile devices. Given the huge proliferation of devices incl. idevices in recent years, it's annoying that we do not have the same options.
I just tried looking for a way to disable said CA in iOS and can't find a way to do so. Maybe someone else has figured this out. Halp?
My frustration is with mobile devices. Given the huge proliferation of devices incl. idevices in recent years, it's annoying that we do not have the same options.
I just tried looking for a way to disable said CA in iOS and can't find a way to do so. Maybe someone else has figured this out. Halp?
>>I'll decide who I trust as and when I have to.
Check out Convergence, which sounds like exactly what you are looking for. http://convergence.io/index.html
Check out Convergence, which sounds like exactly what you are looking for. http://convergence.io/index.html
Users will not understand that TURKTRUST did something wrong. They just see that Chrome is broken. More abstractly, one of the problems of the CA system is, that no one has any incentive to do the right thing. CAs will try to
hide a breach in the chain of trust, since discovering the coverup is no worse for them than discovering the original breach. And blacklisting a CA in a browser will degrade the user experience, so browser vendors are reluctant to do so.
I don't generally like the "strikes and you're out" analogy, but in cases such as this, I find myself favoring a "one strike and you're out" policy. Or zero strikes, if we could force through effective audits.
If nothing else, maybe this would put the fear of [entity] into the organizations in question. The erstwhile incompetent ones. The malicious ones, we just need to give the boot, already.
If nothing else, maybe this would put the fear of [entity] into the organizations in question. The erstwhile incompetent ones. The malicious ones, we just need to give the boot, already.
[deleted]
pretty obvious?
It's obvious because they issued and discovered it was being used for google.com certs.
If it had been innocuously issued, no one would have attempted to issue google.com certs.
Google is in a better position to detect evil google.com certs in use. There's every reason to suspect other evil certs were issued and in use as well (although google.com is probably the most attractive mainstream target; compromising gmail is important to most intelligence and police agencies).
If it had been innocuously issued, no one would have attempted to issue google.com certs.
Google is in a better position to detect evil google.com certs in use. There's every reason to suspect other evil certs were issued and in use as well (although google.com is probably the most attractive mainstream target; compromising gmail is important to most intelligence and police agencies).
I wouldn't call it fairly obvious, but according to this comment -> http://news.ycombinator.com/item?id=5003707 -> the CAs issued included "*.EGO.GOV.TR," which then created the fake Google certificate. If a government entity got access and then did this, you could establish a link between TurkTrust & the government for creating the CA.
That being said, I'd hope that someone researches and figures out why the certificates were issued, to whom, and for what purpose.
That being said, I'd hope that someone researches and figures out why the certificates were issued, to whom, and for what purpose.
Well, with the help of Google Translate, it appears to be the public transit body of the city of Ankara. If I was an evil government body, I'd ask for my intermediate CA cert to be issued in the name of JohnDoesInconspicuousWidgets.com, not a government organisation.
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."
How am I supposed to trust an official Google security blog named "googleonlinesecurity.blogspot.com"? What a bizarre place to put your security blog!
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...
Here is Google's blog directory.. all on blogspot, their blogging platform:
https://www.google.com/intl/en/press/blog-directory.html#tab...
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?
Indeed. I went ahead and created http://googleinternetsecurity.blogspot.com as a proof of concept. I wonder whether it will be allowed to exist.
Except anyone can create a blogspot url. So someone could just create something similar (for a short time at least).
There's no reason it has to be on a blogspot.com subdomain. They could easily put it on a custom subdomain of Google.com and leave no question about whether it's official or a scam. http://support.google.com/blogger/bin/static.py?hl=en&ts...
I guess with long familiarity, many of us just recognize it as a/the legitimate source.
That said, if they move it under the google.com domain, I hope they do not update it to use one of those blank-awful new Blogspot templates that coerce the use of Javascript (or the Google cache) to see anything. There would be, indeed -- from my perspective -- a bit of a contradiction (making me run their Javascript).
That said, if they move it under the google.com domain, I hope they do not update it to use one of those blank-awful new Blogspot templates that coerce the use of Javascript (or the Google cache) to see anything. There would be, indeed -- from my perspective -- a bit of a contradiction (making me run their Javascript).
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).
If so, then current SSL should be regarded as 'broken' effective immediately and not used for secure transactions with Google (and probably anybody else).
At least on my Android devices, you can select which root CAs to trust via Setting -> Security -> Trusted Credentials. Click on TURKTRUST, scroll down and click "Disable". Repeat.
YMMV as I'm running Jelly Bean on both phone (CM10.1) and tablets (stock).
YMMV as I'm running Jelly Bean on both phone (CM10.1) and tablets (stock).
I don't know about anyone else, but I just tried this on my Galaxy Note 2 and the first certificate was a TURKTRUST certificate! Apparently, it sorted that way because the name started with "(c) 2005". There was also another certificate further down, but I'm amazed by the apparent coincidence (unless sloppy procedures led to an unusual certificate name, I suppose).
I would assume the cert was revoked, this is about how they do not trust any cert signed by the same authority.
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?
Do SSL libraries in Java/ObjC use OCSP correctly? As far as I can tell, Android has OCSP disabled by default as the increased latency can be harmful on mobile. I believe Firefox has OCSP disabled by default as well?
> Which means all Android/iOS apps that rely on a secure channel
> to a *.google.com domain can be MITMed?
That's hardly the same thing - you have to actually run/install something on the Android device itself.
With this fake Google certificate, I can install a box between 2 routers anywhere between you and Google - say on an open wifi hotspot or in your ISP's server room. I can then set up a simple transparent forwarding proxy that will provide the fake Google certificate for any Google SSL requests, and forward on other requests as normal. I can then log all data passed between you and Google, such as session cookies, emails, credit card details on Google wallet, etc.
This is extremely problematic as it is effectively invisible to users and can be easily used by governments such as China to ensure they have full access to anybody's encrypted communications with no risk to themselves and very little chance of being detected.
Basically, SSL, HTTPS and anything else relying on CA certs should be regarded as broken, and you should even expect that a hostile government will be listening in. USA government, for example, has full access to AT&Ts server rooms and backbone routes. China has full access and control of any network infrastructure involving communications over Chinese borders.
With this fake Google certificate, I can install a box between 2 routers anywhere between you and Google - say on an open wifi hotspot or in your ISP's server room. I can then set up a simple transparent forwarding proxy that will provide the fake Google certificate for any Google SSL requests, and forward on other requests as normal. I can then log all data passed between you and Google, such as session cookies, emails, credit card details on Google wallet, etc.
This is extremely problematic as it is effectively invisible to users and can be easily used by governments such as China to ensure they have full access to anybody's encrypted communications with no risk to themselves and very little chance of being detected.
Basically, SSL, HTTPS and anything else relying on CA certs should be regarded as broken, and you should even expect that a hostile government will be listening in. USA government, for example, has full access to AT&Ts server rooms and backbone routes. China has full access and control of any network infrastructure involving communications over Chinese borders.
> That's hardly the same thing - you have to actually
> run/install something on the Android device itself.
The general issue is that if your communication between your device and server is going over HTTP, then anybody can sniff it and modify it. This is pretty well known, and the 'solution' is to use SSL.
Unfortunately with these open .google.com certificates in the wild, any android device that would have been securely connecting with SSL to a google server is now wide open to MITM as if it wasn't using SSL at all. I mentioned .google.com in particular since that's the certs floating in the wild, but obviously certs could be made for any site. *.google.com is also of particular issue as your Android device will hold a secure channel open for commands from Google Play. Anybody who can pretend to be Google Play can add/remove applications from your device as they wish, and Google Play itself runs with elevated privileges and can be used to keylog passwords, intercept credit cards, etc. This is bad stuff, man.
At this very minute, someone may have installed a fake cert at your ISP, and your Android device may in fact be compromised without you having any idea. Obviously a completely different issue to hijacking traffic in a controlled environment!
Unfortunately with these open .google.com certificates in the wild, any android device that would have been securely connecting with SSL to a google server is now wide open to MITM as if it wasn't using SSL at all. I mentioned .google.com in particular since that's the certs floating in the wild, but obviously certs could be made for any site. *.google.com is also of particular issue as your Android device will hold a secure channel open for commands from Google Play. Anybody who can pretend to be Google Play can add/remove applications from your device as they wish, and Google Play itself runs with elevated privileges and can be used to keylog passwords, intercept credit cards, etc. This is bad stuff, man.
At this very minute, someone may have installed a fake cert at your ISP, and your Android device may in fact be compromised without you having any idea. Obviously a completely different issue to hijacking traffic in a controlled environment!
I kind of wish we went to the SSH model, where you accept the identity of all servers you visit, and you get loud warnings whenever the identity changes.
But even that has huge problems. (For example, who ever double-checks their SSH server fingerprints in their known_hosts file?)
But even that has huge problems. (For example, who ever double-checks their SSH server fingerprints in their known_hosts file?)
That's what SSHFP records are for. You store the fingerprint of the SSH server in DNS and then turn on a setting in your ~/.ssh/config and it will check for you if it matches with DNS when you try to connect. Even without DNSSEC it creates another thing which needs to be spoofed.
That's mostly what certificate pinning does already, if I'm understanding the concept right.
You can implement that by installing the CertificatePatrol addon for Firefox.
[deleted]
The CA system is fscked beyond repair (it always has been). We need an alternative now.
Supporting http://tack.io/ is imo the most painless solution for what we have right now.
Judging by how Google says they stumbled over this, "Chrome detected and blocked an unauthorized digital certificate", it seems that's roughly what they're doing. I wonder how many sites it's able to do this for.
(but yes, that is definitely a good solution)
(but yes, that is definitely a good solution)
You can see the pins list at
https://src.chromium.org/viewvc/chrome/trunk/src/net/base/tr...
Those are the sites that they're currently able to do it for. :-)
If anyone reading wants to have your own site added to the HSTS preload (or perhaps cert pin) lists, I think the Chromium developers are interested in hearing from you. I know they'll add HSTS preloads for any site, but I don't know for sure whether there's a size or popularity threshold of some sort for a cert pin.
https://src.chromium.org/viewvc/chrome/trunk/src/net/base/tr...
Those are the sites that they're currently able to do it for. :-)
If anyone reading wants to have your own site added to the HSTS preload (or perhaps cert pin) lists, I think the Chromium developers are interested in hearing from you. I know they'll add HSTS preloads for any site, but I don't know for sure whether there's a size or popularity threshold of some sort for a cert pin.
Chrome (the browser) is super-paranoid about other people replacing google.com certificates. It knows exactly what they should be and anything else is cause for alarm. 'tptacek talks about it from time to time.
Indeed. Chrome has baked-in public key pinning for their services.
http://www.imperialviolet.org/2011/05/04/pinning.html
http://www.imperialviolet.org/2011/05/04/pinning.html
It looks like it's still in the development phase? I'd like to start recommending it to clients, and then testing it on client sites, but right now I can't.
EDIT: Oh, apparently plug ins for nginx and apache are now available. Sweeeeet.
EDIT: Although I'm a bit nervous about turning it on. Several weeks ago I couldn't get to one of my websites where I had turned on HSTS for about an hour from Chrome, and I got absolutely no feedback from Chrome about what the problem was.
EDIT: Oh, apparently plug ins for nginx and apache are now available. Sweeeeet.
EDIT: Although I'm a bit nervous about turning it on. Several weeks ago I couldn't get to one of my websites where I had turned on HSTS for about an hour from Chrome, and I got absolutely no feedback from Chrome about what the problem was.
Was HSTS the problem? Or did it end up being something else?
I still don't know, which is why it is such a nagging problem in my gut.
Chrome acted like it was HSTS, because it refused to let me connect at all, not even with a "it's okay to connect for now." And it went away by itself after about 30-60 minutes.
I'm sure I could have wiped out some Chrome settings to fix this, but this site is also used by our customers, and I really really wanted to understand what it was. Fortunately I was the only person who has ever ran into it so far.
Is there an HSTS user group I could ask about this?
Chrome acted like it was HSTS, because it refused to let me connect at all, not even with a "it's okay to connect for now." And it went away by itself after about 30-60 minutes.
I'm sure I could have wiped out some Chrome settings to fix this, but this site is also used by our customers, and I really really wanted to understand what it was. Fortunately I was the only person who has ever ran into it so far.
Is there an HSTS user group I could ask about this?
You could always ask agl, he might have some suggestions.
What I've seen in the past is that Chrome occasionally gets over aggressive in caching (in an attempt to be "fast" I guess). Clearing all the caches out, flushing DNS etc. usually fixes it for me.
What I've seen in the past is that Chrome occasionally gets over aggressive in caching (in an attempt to be "fast" I guess). Clearing all the caches out, flushing DNS etc. usually fixes it for me.
The best thing right now is cert pinning in Chrome. Unfortunately it's only in Chrome, and is a manual process on Google's part, so it really isn't applicable to a lot of people.
Gah, I hate the edit timeout, I meant key pinning. (the key is actually what gets hashed and pinned, not the cert, since certs get reissued all the time for administrative reasons)
Do you know of any alternatives being worked on? No snark intended, I am genuinely curious about the current state of affairs.
Check out http://tack.io/ and http://convergence.io/
You could also listen to this if that's your preferred way of learning things:
https://threatpost.com/en_us/blogs/moxie-marlinspike-tack-co...
You could also listen to this if that's your preferred way of learning things:
https://threatpost.com/en_us/blogs/moxie-marlinspike-tack-co...
Last time Convergence was crapping out when using private (or otherwise unreachable) IPs - kind of makes sense, but still dissapointing. Will check out tack.io and CurveCP, cheers for the suggestions.
There's DANE [1], which uses DNSSEC to authenticate TLS certificates. Chrome supports (or at least supported) something very similar but Chome-specific [2]. The code to support DANE in Chrome apparently exists but I don't know if it's actually available to use. [3]
1. http://datatracker.ietf.org/doc/rfc6698/
2. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
3. http://www.imperialviolet.org/2012/10/20/dane-stapled-certif...
1. http://datatracker.ietf.org/doc/rfc6698/
2. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
3. http://www.imperialviolet.org/2012/10/20/dane-stapled-certif...
There's also CurveCP (http://curvecp.org/) which is a more radical alternative (replaces TCP and relies on DNSCurve, a DNS replacement) but has good security built in by default and some interesting features (remote users are identified by their public key so they can reconnect from different IP addresses and the stream keeps going without a reconnect).
It seems like a much harder thing to get adoption going for but it has good thought behind it and can exist in parallel with the rest of the TCP/IP world. I would love to see it get to a place where you can just download it from Debian or Homebrew...
It seems like a much harder thing to get adoption going for but it has good thought behind it and can exist in parallel with the rest of the TCP/IP world. I would love to see it get to a place where you can just download it from Debian or Homebrew...
I've been using CurveCP for over a year privately and love it. I'll probably expand to production, starting with CurveHTTP, with the next release of NaCl. Not sure if that makes me the chicken or the egg.
[deleted]
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:
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...
[3] http://www.youtube.com/watch?v=Z7Wl2FW2TcA
* 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]
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...
[3] http://www.youtube.com/watch?v=Z7Wl2FW2TcA
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.
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.
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.
no-one has mentioned perspectives (perhaps arguably because it's not an alternative, but a patch to help make the existing approach more reliable), but it exists now and seems to work - https://chrome.google.com/webstore/detail/perspectives/lnppf... https://addons.mozilla.org/en-us/firefox/addon/perspectives/
[deleted]
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?
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?
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.
As you can see, it doesn't even take pervasive deployment of a technology like TACK to significantly mitigate the threat of rogue CAs.
I wonder if EFF SSL Observatory detected anything suspicious about the phony certificates.
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!
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!
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.
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.
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
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.
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.
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.
Prove to whom? The people that issued this cert were effectively (albeit mistakenly) a certificate authority. They could issue whatever certs they liked.
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
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...
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.