9 ms·

Enhancing digital certificate security (Fake *.Google.com cert issued)

181 points by cleverjake 14y ago

RyanZAG 14y ago
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 14y ago
  I would assume the cert was revoked, this is about how they do not trust any cert signed by the same authority.
  - lmz 14y ago
    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?
  - RyanZAG 14y ago
    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?
- kanzure 14y ago
  > Which means all Android/iOS apps that rely on a secure channel > to a *.google.com domain can be MITMed? http://mitmproxy.org/doc/certinstall/android.html http://mitmproxy.org/doc/certinstall/android.html
  - RyanZAG 14y ago
    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.
    - deleted 14y ago
      [deleted]
    - gcr 14y ago
      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?)
      - caf 14y ago
        You can implement that by installing the CertificatePatrol addon for Firefox.
      - mpyne 14y ago
        That's mostly what certificate pinning does already, if I'm understanding the concept right.
      - 14y ago
- jrabone 14y ago
  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).
  - fpgeek 14y ago
    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).
dchest 14y ago
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-advisory-2798897-released-certificate-trust-list-updated.aspx http://blogs.technet.com/b/msrc/archive/2013/01/03/security-...
rdl 14y ago
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.
- cpa 14y ago
  pretty obvious?
  - Shank 14y ago
    I wouldn't call it fairly obvious, but according to this comment -> http://news.ycombinator.com/item?id=5003707 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.
    - mseebach 14y ago
      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.
  - rdl 14y ago
    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).
Nux 14y ago
The CA system is fscked beyond repair (it always has been). We need an alternative now.
- loungin 14y ago
  Do you know of any alternatives being worked on? No snark intended, I am genuinely curious about the current state of affairs.
  - casca 14y ago
    Check out http://tack.io/ http://tack.io/ and http://convergence.io/ 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-convergence-and-trust-agility-053012 https://threatpost.com/en_us/blogs/moxie-marlinspike-tack-co...
    - Nux 14y ago
      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.
  - paul_odin 14y ago
    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/ http://datatracker.ietf.org/doc/rfc6698/ 2. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html 3. http://www.imperialviolet.org/2012/10/20/dane-stapled-certificates.html http://www.imperialviolet.org/2012/10/20/dane-stapled-certif...
  - __david__ 14y ago
    There's also CurveCP (http://curvecp.org/ 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...
mrb 14y ago
"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 http://www.turktrust.com.tr/sil/TURKTRUST_Kok_SIL_s3.crl [2] http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_s3.crl http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_s3.c... [3] http://www.turktrust.com.tr/sertifikalar/19_TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi.crt http://www.turktrust.com.tr/sertifikalar/19_TURKTRUST_Elektr... [4] http://www.turktrust.com.tr/sertifikalar/20_TURKTRUST_Nitelikli_Elektronik_Sertifika_Hizmetleri.crt http://www.turktrust.com.tr/sertifikalar/20_TURKTRUST_Niteli...
- yk 14y ago
  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.html http://events.ccc.de/congress/2012/Fahrplan/events/5319.en.h...
aaronharnly 14y ago
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 14y ago
  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#tab0 https://www.google.com/intl/en/press/blog-directory.html#tab...
  - jzwinck 14y ago
    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 14y ago
      Indeed. I went ahead and created http://googleinternetsecurity.blogspot.com http://googleinternetsecurity.blogspot.com as a proof of concept. I wonder whether it will be allowed to exist.
  - illumen 14y ago
    Except anyone can create a blogspot url. So someone could just create something similar (for a short time at least).
  - ceejayoz 14y ago
    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=1233381&page=ts.cs http://support.google.com/blogger/bin/static.py?hl=en&ts...
- pasbesoin 14y ago
  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).
huhtenberg 14y ago
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 14y ago
  > 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 14y ago
    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.)
chayesfss 14y ago
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
biturd 14y ago
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 14y ago
  Prove to whom? The people that issued this cert were effectively (albeit mistakenly) a certificate authority. They could issue whatever certs they liked.
mixedbit 14y ago
I wonder if EFF SSL Observatory detected anything suspicious about the phony certificates.
- schoen 14y ago
  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 14y ago
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 14y ago
  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 http://d.pr/i/c8Tx
  - biturd 14y ago
    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.
moxie 14y ago
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-ssl-but-your-app-ha/ 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 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 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 http://www.thoughtcrime.org/software/sslstrip) attacks.
- kevinburke 14y ago
  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 14y ago
    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.
  - asdfaoeu 14y ago
    Presumably it still checks the certificate is valid otherwise the worse case would just be that the legitimate site would not work.
erydo 14y ago
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 14y ago
  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.

181 points by cleverjake 14y ago

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 14y ago
I would assume the cert was revoked, this is about how they do not trust any cert signed by the same authority.
- lmz 14y ago
  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?
- RyanZAG 14y ago
  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?
kanzure 14y ago
> Which means all Android/iOS apps that rely on a secure channel > to a *.google.com domain can be MITMed? http://mitmproxy.org/doc/certinstall/android.html http://mitmproxy.org/doc/certinstall/android.html
- RyanZAG 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - gcr 14y ago
    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?)
    - caf 14y ago
      You can implement that by installing the CertificatePatrol addon for Firefox.
    - mpyne 14y ago
      That's mostly what certificate pinning does already, if I'm understanding the concept right.
    - 14y ago
jrabone 14y ago
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).
- fpgeek 14y ago
  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).

dchest 14y ago

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-advisory-2798897-released-certificate-trust-list-updated.aspx http://blogs.technet.com/b/msrc/archive/2013/01/03/security-...

rdl 14y ago

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.

cpa 14y ago
pretty obvious?
- Shank 14y ago
  I wouldn't call it fairly obvious, but according to this comment -> http://news.ycombinator.com/item?id=5003707 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.
  - mseebach 14y ago
    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.
- rdl 14y ago
  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).

Nux 14y ago

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

loungin 14y ago
Do you know of any alternatives being worked on? No snark intended, I am genuinely curious about the current state of affairs.
- casca 14y ago
  Check out http://tack.io/ http://tack.io/ and http://convergence.io/ 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-convergence-and-trust-agility-053012 https://threatpost.com/en_us/blogs/moxie-marlinspike-tack-co...
  - Nux 14y ago
    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.
- paul_odin 14y ago
  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/ http://datatracker.ietf.org/doc/rfc6698/ 2. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html 3. http://www.imperialviolet.org/2012/10/20/dane-stapled-certificates.html http://www.imperialviolet.org/2012/10/20/dane-stapled-certif...
- __david__ 14y ago
  There's also CurveCP (http://curvecp.org/ 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...

mrb 14y ago

"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 http://www.turktrust.com.tr/sil/TURKTRUST_Kok_SIL_s3.crl [2] http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_s3.crl http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_s3.c... [3] http://www.turktrust.com.tr/sertifikalar/19_TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi.crt http://www.turktrust.com.tr/sertifikalar/19_TURKTRUST_Elektr... [4] http://www.turktrust.com.tr/sertifikalar/20_TURKTRUST_Nitelikli_Elektronik_Sertifika_Hizmetleri.crt http://www.turktrust.com.tr/sertifikalar/20_TURKTRUST_Niteli...

yk 14y ago
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.html http://events.ccc.de/congress/2012/Fahrplan/events/5319.en.h...

aaronharnly 14y ago

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 14y ago
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#tab0 https://www.google.com/intl/en/press/blog-directory.html#tab...
- jzwinck 14y ago
  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 14y ago
    Indeed. I went ahead and created http://googleinternetsecurity.blogspot.com http://googleinternetsecurity.blogspot.com as a proof of concept. I wonder whether it will be allowed to exist.
- illumen 14y ago
  Except anyone can create a blogspot url. So someone could just create something similar (for a short time at least).
- ceejayoz 14y ago
  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=1233381&page=ts.cs http://support.google.com/blogger/bin/static.py?hl=en&ts...
pasbesoin 14y ago
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).

huhtenberg 14y ago

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 14y ago
> 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 14y ago
  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.)

chayesfss 14y ago

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

biturd 14y ago

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 14y ago
Prove to whom? The people that issued this cert were effectively (albeit mistakenly) a certificate authority. They could issue whatever certs they liked.

mixedbit 14y ago

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

schoen 14y ago
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 14y ago

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 14y ago
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 http://d.pr/i/c8Tx
- biturd 14y ago
  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.

moxie 14y ago

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-ssl-but-your-app-ha/ 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 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 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 http://www.thoughtcrime.org/software/sslstrip) attacks.

kevinburke 14y ago
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 14y ago
  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.
- asdfaoeu 14y ago
  Presumably it still checks the certificate is valid otherwise the worse case would just be that the legitimate site would not work.

erydo 14y ago

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 14y ago
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.