Linked by HAL2001 on Mon 5th Sep 2011 14:15 UTC
Privacy, Security, Encryption 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.
Order by: Score:
Little Irony, you're so wicked!
by vodoomoth on Mon 5th Sep 2011 14:41 UTC
vodoomoth
Member since:
2010-03-30

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.

Reply Score: 4

Well duh.
by Thom_Holwerda on Mon 5th Sep 2011 14:49 UTC
Thom_Holwerda
Member since:
2005-06-29

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.

Reply Score: 2

RE: Well duh.
by ameasures on Mon 5th Sep 2011 20:14 UTC in reply to "Well duh."
ameasures Member since:
2006-01-09

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

Reply Score: 2

RE[2]: Well duh.
by Lennie on Mon 5th Sep 2011 21:41 UTC in reply to "RE: Well duh."
Lennie Member since:
2007-09-22

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.

Reply Score: 2

RE: Well duh.
by Valhalla on Tue 6th Sep 2011 07:53 UTC in reply to "Well duh."
Valhalla Member since:
2006-01-24

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.

Well if that's the only downside to legal cannabis, I say 'pass the dutchie!' ;)

Reply Score: 2

Can't trust this
by JimProfit on Mon 5th Sep 2011 15:01 UTC
JimProfit
Member since:
2011-08-03

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

Reply Score: 1

SSL secret root keys
by Alfman on Mon 5th Sep 2011 15:55 UTC
Alfman
Member since:
2011-01-28

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.

Reply Score: 3

RE: SSL secret root keys
by Not2Sure on Mon 5th Sep 2011 17:57 UTC in reply to "SSL secret root keys"
Not2Sure Member since:
2009-12-07

It so far appears to have been an external breach originating from "within" Iran. Whatever within means anymore.

Reply Score: 1

RE: SSL secret root keys
by ddc_ on Mon 5th Sep 2011 18:22 UTC in reply to "SSL secret root keys"
ddc_ Member since:
2006-12-05

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.

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.

Reply Score: 3

RE[2]: SSL secret root keys
by Alfman on Mon 5th Sep 2011 20:15 UTC in reply to "RE: SSL secret root keys"
Alfman Member since:
2011-01-28

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

Reply Score: 3

RE[3]: SSL secret root keys
by Lennie on Mon 5th Sep 2011 21:33 UTC in reply to "RE[2]: SSL secret root keys"
Lennie Member since:
2007-09-22

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.

Reply Score: 3

RE[4]: SSL secret root keys
by Alfman on Mon 5th Sep 2011 21:41 UTC in reply to "RE[3]: SSL secret root keys"
Alfman Member since:
2011-01-28

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?

Reply Score: 2

RE[5]: SSL secret root keys
by Lennie on Tue 6th Sep 2011 00:15 UTC in reply to "RE[4]: SSL secret root keys"
Lennie Member since:
2007-09-22

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.

Reply Score: 3

RE[3]: SSL secret root keys
by ddc_ on Tue 6th Sep 2011 17:25 UTC in reply to "RE[2]: SSL secret root keys"
ddc_ Member since:
2006-12-05

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.
I was referring to pre-shared keys. Sorry for not making it clear enough.

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

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.
Everything is practical when it is sufficient minimum.

Reply Score: 1

RE[4]: SSL secret root keys
by Alfman on Tue 6th Sep 2011 18:41 UTC in reply to "RE[3]: SSL secret root keys"
Alfman Member since:
2011-01-28

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.

Reply Score: 2

What browser vendors need to learn
by Kroc on Mon 5th Sep 2011 16:56 UTC
Kroc
Member since:
2005-11-10

Encryption != identity

Reply Score: 3

Alfman Member since:
2011-01-28

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.

Reply Score: 3

Not2Sure Member since:
2009-12-07

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.

Reply Score: 2

mabhatter Member since:
2005-07-17

obligatory XKCD
http://xkcd.com/932/

Reply Score: 3

Delgarde Member since:
2008-08-19

Encryption != identity


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.

Reply Score: 3

So ...
by WorknMan on Mon 5th Sep 2011 21:55 UTC
WorknMan
Member since:
2005-11-13

Is this like the HDCP encryption where, when/if somebody gets the master key, it's pretty much game over?

Reply Score: 2

RE: So ...
by Alfman on Mon 5th Sep 2011 22:16 UTC in reply to "So ..."
Alfman Member since:
2011-01-28

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.

Reply Score: 3

RE[2]: So ...
by tidux on Tue 6th Sep 2011 01:36 UTC in reply to "RE: So ..."
tidux Member since:
2011-08-13

And so, yet another reason for letting IE<=8 die appears.

Reply Score: 2