An update on attempted man-in-the-middle attacks(googleonlinesecurity.blogspot.com)
googleonlinesecurity.blogspot.com
An update on attempted man-in-the-middle attacks
http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html
17 comments
IMHO, just blacklisting these resellers is worthless as there is obviously not enough oversight over who can be a reselling CA.
This is the third time this year that a Comodo reseller has been breached. Comodo should scrutinize their customers better or THEY should get blacklisted (taking all their other resellers with them) at least until they made sure that their clients have all resolved their security issues
This is the third time this year that a Comodo reseller has been breached. Comodo should scrutinize their customers better or THEY should get blacklisted (taking all their other resellers with them) at least until they made sure that their clients have all resolved their security issues
This is not a Comodo reseller. This is a root CA. Your browser has its own entry for DigiNotar in it.
It's heartening but it's also not. Surely there have been many other cases of invalid certs being granted for lower profile sites, perhaps by this very same CA, without any of us ever hearing about it. And surely the granter of one of those is still considered valid within many browser/OS configurations. But because this was an invalid Google cert the CA gets shut down.
It kind of highlights the difficult problem of when to decide to blacklist a CA in the current model.
And for clarity, who/what do you think is the real power behind Internet trust? I've been thinking about it for five minutes and can't come up with a good answer.
It kind of highlights the difficult problem of when to decide to blacklist a CA in the current model.
And for clarity, who/what do you think is the real power behind Internet trust? I've been thinking about it for five minutes and can't come up with a good answer.
Browser vendors, perhaps?
And OS vendors. And whoever configures the computer. You buy a computer that was made in China, and it has root certs already in there (thanks to either Microsoft or Apple, or the shop who sold it, or the guys who assembled it - who knows?). Chome / Safari uses the system certs. All good, right?
[deleted]
who/what do you think is the real power behind Internet trust
Nobody, it's all fiat. Verisign started this scam and we're just seeing the follow-on effects. There has never been anything more than the words and policies supporting the CA industry.
Nobody, it's all fiat. Verisign started this scam and we're just seeing the follow-on effects. There has never been anything more than the words and policies supporting the CA industry.
Was the CA definitely complicit in this attack? I always assume that private companies have little recourse at state scales of force.
Either the CA was complicit, or they weren't secure. Regardless of which it is, the CA's root certificate is not trustworthy.
If they were hacked into, spoofed into giving out a certificate, or raided by special forces and had data physically stolen from their servers, then perhaps they can generate a new key and have that become trusted once they've taken steps to ensure something like this doesn't happen again.
But there's no way anyone can trust their old root key anymore.
If they were hacked into, spoofed into giving out a certificate, or raided by special forces and had data physically stolen from their servers, then perhaps they can generate a new key and have that become trusted once they've taken steps to ensure something like this doesn't happen again.
But there's no way anyone can trust their old root key anymore.
Does it matter whether they were complicit or simply compromised? Either way they shouldn't be trusted.
I wanted to give convergence.io a try, but - they offer a Firefox addon that doesn't install for FF 6.
Nice website, no idea if it works. Sounds cool, but more Beta than a Google Beta I guess.
Nice website, no idea if it works. Sounds cool, but more Beta than a Google Beta I guess.
I tried convergence.io, but it's incompatible with Certificate Patrol. Certificate Patrol is an addon which alerts you to certificate changes.
Has IE switched to auto updating or anything?
I love the fact that Google can push changes out to Chrome users immediately. That's a massive win for everyone.
I love the fact that Google can push changes out to Chrome users immediately. That's a massive win for everyone.
Really? If Chrome's had updates pushed to it recently, how do I know that my browser itself, as installed on my filesystem, isn't now innately subverted by the Iranian government? (Note the domain in question in this particular case.)
I don't know about Chrome's update process, but they can simply have their own verification without root certificates (i.e. just like what most Mac software with Sparkle updater do: keep a public key inside the app, and verify the signature of updates).
Is convergence.io available for Chrome?
I hope, so much, that Convergence.io the future.
But, you said "medium term." What's the long term?
But, you said "medium term." What's the long term?
DigiNotar's mother company Vasco finally released a press statement.
http://www.vasco.com/company/press_room/news_archive/2011/ne...
Just incredible: They were hacked and they knew it, then forgot to clean up a certificate the hackers generated.
http://www.vasco.com/company/press_room/news_archive/2011/ne...
Just incredible: They were hacked and they knew it, then forgot to clean up a certificate the hackers generated.
On July 19th 2011, DigiNotar detected an intrusion into
its Certificate Authority (CA) infrastructure, which
resulted in the fraudulent issuance of public key
certificate requests for a number of domains, including
Google.com.
Once it detected the intrusion, DigiNotar has acted in
accordance with all relevant rules and procedures.
At that time, an external security audit concluded that
all fraudulently issued certificates were revoked.
Recently, it was discovered that at least one fraudulent
certificate had not been revoked at the time. After
being notified by Dutch government organization Govcert,
DigiNotar took immediate action and revoked the
fraudulent certificate.
The attack was targeted solely at DigiNotar's Certificate
Authority infrastructure for issuing SSL and EVSSL
certificates. No other certificate types were issued or
compromised. DigiNotar stresses the fact that the vast
majority of its business, including his Dutch government
business (PKIOverheid) was completely unaffected by the
attack.
This (Dutch) article http://tweakers.net/nieuws/76466/hackers-genereerden-zelf-ve... quotes the spokesperson for DigiNotar, and he claims "we hope that by end of the week our certificates will be trusted by Google, Mozilla and Microsoft again"
FF nightly builds also block the PKIOverheid CA which signs the certificates for key Dutch government websites and services (DigiD). Mozilla is going to have a fun time with Dutch users/Dutch Government/DigiNotar
My understanding is that what Mozilla is going to ship will not block PKIOverheid. See https://bugzilla.mozilla.org/show_bug.cgi?id=682956#c17
a number of domains, including Google.com
But nowhere do they appear to include a list of these domains...
But nowhere do they appear to include a list of these domains...
Do we really need all those Certificate Authorities that are trusted by the browser? I remember 10 years ago Verisign would spend time verifying a business digging through legal documents, addresses, company officers, notarized docs, etc. Nowadays I'm supposed to trust a bunch of fly-by-night operations issuing certificates for a dollar and a song.
There are two sides to that, right?
You're building a new startup in (whatever) Bulgaria. Funds are low, but you want to protect your users by using TLS/SSL. That's easy today, but your 'Think of the good old days' line is kind of killing that option. I know that in my early 'put something on the net' days I didn't pay for a certificate because it was just too expensive.
Nevermind that the process you seem to expect doesn't scale internationally and that I seriously dislike the US centric bias anyway (too much power in one country, without the privacy laws I consider basic standard).
You're building a new startup in (whatever) Bulgaria. Funds are low, but you want to protect your users by using TLS/SSL. That's easy today, but your 'Think of the good old days' line is kind of killing that option. I know that in my early 'put something on the net' days I didn't pay for a certificate because it was just too expensive.
Nevermind that the process you seem to expect doesn't scale internationally and that I seriously dislike the US centric bias anyway (too much power in one country, without the privacy laws I consider basic standard).
What we need, I think, is for browsers to display the CA as well as the URL. As in, 'DigiNotar certifies that you are connected to gmail'. This won't wholly solve the problem, but it will a) broaden the knowledge that CA's actually exist, and thus the problem of trusting them and b) provide some reputational disincentive to being a bad CA.
Unfortunately chrome seems to be headed in the opposite direction, removing the URL bar.
Unfortunately chrome seems to be headed in the opposite direction, removing the URL bar.
Click on the padlock, and it tells you all of that.
eg "The identity of this website has been verified by Thawte SGC CA."
eg "The identity of this website has been verified by Thawte SGC CA."
Thanks. However since it didn't even occur to me to do that, it doesn't seem likely that many less technical people will do it.
Less technical people will never understand, much less care, what a CA is. It's hard anything explaining the concept of a URL!
There are lots of people between 'a HN reader' and 'your grandmother'.
There will always be people who don't understand what a CA is; but the more people who do, the more pressure there will be for them to do their job correctly.
Also, they don't need to understand the technical details. If every time they go to their bank it says 'connection to your bank certified by verisign', and then one day it says 'certified by <someone else>', then a cautious person will be suspicious, even if they are completely nontechnical.
Also, they don't need to understand the technical details. If every time they go to their bank it says 'connection to your bank certified by verisign', and then one day it says 'certified by <someone else>', then a cautious person will be suspicious, even if they are completely nontechnical.
There are much better ways to notify users than trying to convince them of the value of monitoring their bank's CA. The browser could simply keep track of the cert and notify the user if it changes unexpectedly. This doesn't require the user to understand anything new, and it still works in the case that the fraudulent cert is signed by Verisign.
It's a shame that the only real protection against rogue (or compromised) CAs is still to have a whitelist directly in the browser.
For Google, this was easy as they control both their domains and their browser, but for everybody else who isn't maintaining a browser, they'd have to fall back to solutions like STS which, don't work if the first connection a user sees is already man-in-the-middle'd
For Google, this was easy as they control both their domains and their browser, but for everybody else who isn't maintaining a browser, they'd have to fall back to solutions like STS which, don't work if the first connection a user sees is already man-in-the-middle'd
If you want to verify that you no longer support Diginotar CA, this should give you a warning: https://www.diginotar.nl/
I get redirected to http there, but this should show the untrusted CA:
https://www.diginotar.com/Products/ExtendedValidationSSL/tab...
I get redirected to http after clicking on the first link, just like you did, but when I visit the URL you posted in Chrome (on OS X), I'm able to view the encrypted page without a warning.
I changed the settings in Keychain Access hours ago.
Does anyone know what's going on?
I changed the settings in Keychain Access hours ago.
Does anyone know what's going on?
I got the same result. For some reason Chrome trusts intermediate certificate even if the root certificate is marked as untrusted. Screenshot: http://i.imgur.com/qW6V3.png (Chrome 14.0.835.109 beta)
Lock with the warning icon is here because "Unable to check whether the certificate has been revoked."
Maybe their intermediate is signed by some other root CA?
Lock with the warning icon is here because "Unable to check whether the certificate has been revoked."
Maybe their intermediate is signed by some other root CA?
Update: filed a bug http://crbug.com/94732
I get redirected to a non-ssl page ( http://www.diginotar.nl/Default.aspx ) instead, no warning? (Chrome)
Wow, the security features Chrome used to nullify the attack were just implemented in June. I wonder if that was a reaction to another incident like this, or if it was just good foresight?
http://blog.chromium.org/2011/06/new-chromium-security-featu...
> In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against recent incidents[1][2] where a CA has its authority abused, and generally protects against the proliferation of signing authority.
[1] http://googleonlinesecurity.blogspot.com/2011/04/improving-s...
[2] http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
> In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against recent incidents[1][2] where a CA has its authority abused, and generally protects against the proliferation of signing authority.
[1] http://googleonlinesecurity.blogspot.com/2011/04/improving-s...
[2] http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
This isn't the first time something like this has happened. I don't know if they did it in response to any one particular incident, but they have every reason in the world to implement something like that.
The amazing thing is that:
1) it doesn't happen more often
2) that anyone noticed
Its clearly early days. If they had impersonated a download server, they could have got users to download a spiked copy of the browser itself
1) it doesn't happen more often
2) that anyone noticed
Its clearly early days. If they had impersonated a download server, they could have got users to download a spiked copy of the browser itself
There's also the possibility that it does happen often and no one notices, of course.
Makes me wonder how you'd approach the "how do I find bad certs" problem.
You'd think that an entity which, say, scrapes a large portion of the Web on a regular basis ... might be able to detect such things.
Meanwhile, there's CertWatch http://certwatch.simos.info/ and The Convergence Project http://convergence.io/
You'd think that an entity which, say, scrapes a large portion of the Web on a regular basis ... might be able to detect such things.
Meanwhile, there's CertWatch http://certwatch.simos.info/ and The Convergence Project http://convergence.io/
It was easily noticeable thanks to Chrome not trusting it in the first place (which also would have prevented spoofing the download server, though I suspect there's more to protect that than just a key).
The (partial) solution to this problem is very well known and is already implemented by SSH and several other packages that rely on public cryptography:
1) When user visits a new site, the certificate is presented to the user for inspection.
2) On subsequent visits, the site's certificate is compared to the one stored in the browser cache. If they are the same, then the connection is made silently. If there is difference, then the new cert is presented to the user for inspection.
The only problem is that this would kill user experience for 99% of the users who don't care about security in the first place. Thus, browsers need to do some clever UI tricks (e.g. color the thingy in url bar in a different color, etc.) to indicate potential problem to the user yet make it less intrusive.
The bottom line is that the fault is not on the SSL/x509. This infrastructure is not perfect but there is nothing better even in the design. The fault is on the browser developers who are not trying to protect users.
The only problem is that this would kill user experience for 99% of the users who don't care about security in the first place. Thus, browsers need to do some clever UI tricks (e.g. color the thingy in url bar in a different color, etc.) to indicate potential problem to the user yet make it less intrusive.
The bottom line is that the fault is not on the SSL/x509. This infrastructure is not perfect but there is nothing better even in the design. The fault is on the browser developers who are not trying to protect users.
See tptacek's comments from this thread on the earlier post to see why this may not be a great idea:
http://news.ycombinator.com/item?id=2938870
http://news.ycombinator.com/item?id=2938870
There is a Firefox extension 'certificate patrol' using this aproach, see https://addons.mozilla.org/en-US/firefox/addon/certificate-p....
Question: This I believe is a serious issue, but what is the best way to 'reach' out to majority of users in a country?
Should/would google display this blog link on top of every google service to alert users in Iran, regardless of browser?
My thought is this blog may not even reach out to majority of users, till they get affected by it unless it is 'broadcasted'.
Should/would google display this blog link on top of every google service to alert users in Iran, regardless of browser?
My thought is this blog may not even reach out to majority of users, till they get affected by it unless it is 'broadcasted'.
Anyone know a way to remove DigiNotar as a system root CA in OS X? I spent a few minutes struggling with Keychain to no avail, and couldn't Google my way to useful help.
Click "System Roots" on the left, find the CA. Right click then "Get Info". Expand the "Trust" section at the top and select "Never Trust".
I have un-trusted the Chinese CNNIC two operating system versions ago (10.5), and it is still set to the same setting. This seems less fragile than deleting the cert to me.
Thanks! If I were IT support, how could I get this to happen on every Mac in the company?
I am also unable to delete it. Which is strange since there is an option to delete it.
If you cannot delete it, you can edit the trust settings to never trust it.
If you cannot delete it, you can edit the trust settings to never trust it.
Keychain -> System Roots -> Search for DigiNotar -> Right click delete.
Assert it has been removed by navigating to https://www.diginotar.nl/
Assert it has been removed by navigating to https://www.diginotar.nl/
Is that what you really want to do?
What's to keep an OS upgrade from restoring the certificate?
A system or user-maintained blacklist seems like a more tenable solution. You don't want to delete the cert, you want to hang a scarlet letter on it. Oh, and not trust it for anything (or better, use it to blacklist any site that attempts to use it).
What's to keep an OS upgrade from restoring the certificate?
A system or user-maintained blacklist seems like a more tenable solution. You don't want to delete the cert, you want to hang a scarlet letter on it. Oh, and not trust it for anything (or better, use it to blacklist any site that attempts to use it).
[deleted]
At least for me there's no such choice as delete in the System Roots keychain.
The only thing I can do is to set it to "never trust" and still Chrome/Safari show it as trusted: http://imgur.com/NcUYf
Did you try that and it really removed the CA?
Or is it supposed to remove the trust only but keep the entry?
Or is it supposed to remove the trust only but keep the entry?
It removed the entry completely from the Keychain, I am on Lion for reference.
Sanity testing by loading the homepage over HTTPS results in a certificate warning on all browsers (Firefox redirected to HTTP).
Sanity testing by loading the homepage over HTTPS results in a certificate warning on all browsers (Firefox redirected to HTTP).
[deleted]
This seems like a very expensive, targeted, specific attack. The perpetrators will likely succeed (or have already succeeded) at breaking into their intended target.
Someone high-profile in Iran is probably going to get screwed as a result.
Someone high-profile in Iran is probably going to get screwed as a result.
That does not necessarily need to be the case.
I don't know how the CA in question works, but for many CAs it's sufficient to be able to receive mails at the postmaster address of the domain in order to receive a certificate.
So basically you only need to find a single CA that uses this techniques and which uses a DNS server vulnerable to cache poisoning. Probing all of the CAs may be a little bit of an effort, but it's something even a single individual could manage. I would not find it suprising if this was the technique applied in that case.
I don't know how the CA in question works, but for many CAs it's sufficient to be able to receive mails at the postmaster address of the domain in order to receive a certificate.
So basically you only need to find a single CA that uses this techniques and which uses a DNS server vulnerable to cache poisoning. Probing all of the CAs may be a little bit of an effort, but it's something even a single individual could manage. I would not find it suprising if this was the technique applied in that case.
I really wish Chrome would warn me when a site jumps to a new CA or even a new certificate. Last I checked, details on the current certificate wasn't made available to plugins, so I can't easily write it myself.
Any word on whether Iranians are still getting this attack? I would love to see some traceroutes to google.com from affected individuals' machines.
Ouch, DigiNotar is revoked in Chrome? They didn't do anything wrong, someone else pretended to be them.
For somebody else to pretend to be then, in this case, they need their private key. As a CA, you can't have your private key leaked and then still be trusted by a browser.
Or they issued the *.google.com certificate by accident, but if you accidentally issue a certificate as a CA, you can't be trusted by a browser either.
IMHO, this was entirely justified.
Or they issued the *.google.com certificate by accident, but if you accidentally issue a certificate as a CA, you can't be trusted by a browser either.
IMHO, this was entirely justified.
They're being revoked in Firefox and IE too. Their certs are hopefully going to be worthless soon. The ONE THING you ask a CA to do is NOT LET ITS PRIVATE KEY BE USED FOR EVIL. ONE THING.
The only way this attack would have worked is if DigiNotar's private key, whose public key is included in the major CA whitelist in major browsers, signed the domain. So either they did it, or somebody stole their private key. Either way it is very much their responsibility.
And Mozilla products and apparently IE. Serves them right. I hope every time such a thing happens the CA gets kicked out and blacklisted for life.
Sign a Google Mail certificate for Iran? Fuck you. You're done.
In the medium term, I think a lot of HN people should also take a hard look at CONVERGENCE.IO. For now, though, it's heartening to see the real power behind Internet trust (hint: it's not Verisign and it's not the IETF) taking this seriously.