The number of rogue SSL certificates issued by Dutch CA DigiNotar has balooned from one to a couple dozen to over 250 to 531 in just a few days. As Jacob Appelbaum of the Tor project shared the full list of the rogue certificates, it became clear that fraudulent certificates for domains of a number of intelligence agencies from around the world were also issued during the CA’s compromise – including the CIA, MI6 and Mossad. Additional targeted domains include Facebook, Yahoo!, Microsoft, Skype, Twitter, Tor, WordPress and many others.
Is it just me or the idea of a certificate authority being “hacked into” issuing forged certificates is truly ironic? I mean, they are supposed to help provide security to others and their own security has been breached with these consequences? That would be a good case of irony in my eyes. They’re indeed set for never removing the “Closed” sign again.
Never leave anything related to information technology to us Dutch. We WILL fcuk it up. Over the past decade, every IT-related government project has failed. Every. Single. One. It’s a major problem in The Netherlands.
As a Brit, I relate painfully to your sentiment – the question isn’t “Where it is it bad?” but rather “Which country, if any, gets it right?”
Edited 2011-09-05 20:15 UTC
Also I wouldn’t trust the British banks to get it right either:
http://media.ccc.de/browse/congress/2010/27c3-4211-en-chip_and_pin_…
I’m still left thinking, as the Dutch banks also recently started rolling out a similar system, if they did get it right.
Well if that’s the only downside to legal cannabis, I say ‘pass the dutchie!’
Remember that Ben Ali’s Tunisia was given a root certificate, effectively allowing the government to use the same phishing techniques against activists..
http://www.rue89.com/2011/03/18/tunisie-microsoft-complice-de-la-ce…
Does anyone know if the CA key was copied by a network intrusion, or an inside employee?
Either way, it’s clearly an additional weakness of a system which was already faulted several times for being vulnerable to impersonation through the audit process. Anyone remember the fraudulent microsoft cert? Authenticating submissions turns out to be very difficult and not so accurate.
What is the answer? How can I prove that I am connecting to my bank? One answer is to exchange the key physically at the bank and eliminate the core problem with the CA model (requirement of trust in a third party), however this is even less appealing and merely shifts the trust from the CA to the bank’s own vulnerable employees.
It so far appears to have been an external breach originating from “within” Iran. Whatever within means anymore.
Come on, You are valnurable the same way when You arrange a payment in a bank office! Or even just have Your money in a bank. You either trust >our bank (and collect damages if You’re out of luck) or don’t trust and Your money are home hidden under the bath.
And yes, having a key pair (one at bank, one at client’s responsibility) is the most secure way of online banking, just because these two are unavoidable and there’s no third, fourth and nth party in the process.
ddc_,
“Come on, You are valnurable the *same way* when You arrange a payment in a bank office!” (emphasis mine)
When I do banking online, there are a lot more ways I can be vulnerable that the bank has no control over:
1. Buggy/Exploitable code in the OS/browser.
2. Trojans/loggers
3. Fraudulent/confusing SSL certificates
I have a strong cryptographic background and I choose to do my banking online. However it’s pretty clear that online banking today requires the trust of more entities than just walking into the bank.
So, for instance, a corrupt CA could deliberately sign a false SSL certificate, conduct a man in the middle attack while snooping all my traffic, all the while not even alerting either me or my bank to their presence. The bank is powerless to stop this, PKI used today places CA at the top of the trust hierarchy.
Edit: I was assuming that you were referring to an HTTPS security model. However if you were in fact referring to pre-shared keys (such as a keyfob), then that changes things.
Pre-shared key fobs, while secure in cryptographic principal, still rely on trust in the manufacturer not to retain a copy of the keys. Unfortunately, as the recent hacker infiltration of RSA shows, that trust can be misplaced resulting in broken security.
Although this vulnerability could be avoided by initializing the keys only once in the user’s possession (rather than at the manufacturer).
I’d consider the keyfob the “gold standard” of secure digital authentication. Owning a separate keyfob for every bank/ecommerce site is still not practical though.
Edited 2011-09-05 20:29 UTC
Well I’m a programmer, system-administrator and webdeveloper. I know very well how these business operate.
I know a little about how encryption works and that part is never the weakest link in the system. It is always the process, the technology around it and the people running the show.
We have key-fobs here, but I do NOT do online banking.
Lennie,
“I know a little about how encryption works and that part is never the weakest link in the system.”
Agree.
“We have key-fobs here, but I do NOT do online banking.”
Can you elaborate?
In the Netherlands the banks use, thinks like this:
https://bankieren.rabobank.nl/rabo/qsl/images/brt_random_reader_tr_p…
http://image.minoc.com/zd_images/2006/41/061011_blinden.jpg
Maybe you wouldn’t consider that a keyfob.
But I don’t do online banking; I use cash, signature on paper, and so on at the bank.
As banks really want people to use online banking because it is cheaper they are starting to make it really hard to keep doing it like that.
I wonder how the people of age 70+ do it, many don’t do online banking too.
I was referring to pre-shared keys. Sorry for not making it clear enough.
All of this does not apply to any specific encryption (or identification) scheme. It is a case of two generic software problems: software is buggy and software is insecure, as there is no way to reliably prove otherwise for any piece of code.
Therefor the security considerations concerning software implementation are not relevant to the question discussed, as there is no way to avoid this. You either hope to have no problems, either don’t pay wia online services.
Everything is practical when it is sufficient minimum.
ddc_,
“All of this does not apply to any specific encryption (or identification) scheme.”
For the first two, yes. But the possibility of fraudulent certificates through third party CA’s are a consequence of specific encryption/identification schemes. Some schemes depend on trusting a central entity, while others do not. The centralized schemes are more practical on the web, but they are inherently less secure than schemes which don’t involve a third party.
“Therefor the security considerations concerning software implementation are not relevant to the question discussed, as there is no way to avoid this. You either hope to have no problems, either don’t pay wia online services.”
By far and large users won’t have any way to avoid these problems, but how you can say they are not relevant? Anyone planning on using SSL to secure their website should be aware of the vulnerabilities whether they can be avoided or not.
Encryption != identity
Kroc,
“Encryption != identity”
Of course not, but then again I don’t see who was confusing the two?
This isn’t a cryptographic vulnerability with the browsers, it’s a problem stemming from the fact that the PKI is controlled by third party CAs. It’s not really the browser vendors’ fault at all.
It’s really hard to learn anything here, PKI depends on trusting third parties. We could revert to preshared keys to eliminate the dependence on CAs, but that’s highly impractical for the web.
Umm.. this is a compromised root authority granting certificates. It is exactly an identity problem.
Not only just man-in-middle https encryption attack vectors of hard-coded trusted identities in browsers via dns poisoning (which it appears was actually used within Iran http://blog.trendmicro.com/diginotar-iranians-the-real-target/ )
But, some of the rogue certificates also had signing permissions; appears that certs for *.google.com and *.android.com had signing ability which means attackers with the certificates for more than a month had the ability to package, sign, and attempt to distribute binary drivers, applications, etc.
obligatory XKCD
http://xkcd.com/932/
No, but they’re closely related. Both rely on the certificate infrastructure actually being trustworthy – otherwise you can’t be certain who you’re talking to, or who else might be able to read your encrypted conversation.
Is this like the HDCP encryption where, when/if somebody gets the master key, it’s pretty much game over?
WorknMan,
“Is this like the HDCP encryption where, when/if somebody gets the master key, it’s pretty much game over?”
PKI has some failsafe protections. If a fraudulent certificate is issued accidentally, or a legitimate one is leaked, then a protocol exists to revoke it (using the master keys).
However in this case it appears that one or all of the CA’s master keys were compromised. This means that the cracker can now do everything that the CA could have done itself. They can issue fraudulent certificates to impersonate any web site. Until web browsers are updated, the fraudulent certificates will continue to validate in web browsers.
And so, yet another reason for letting IE<=8 die appears.