> Revoking certificates will cause unpleasant SSL errors.

Unpleasant errors scares away buyers. That is, Error + Credit Card = No Purchase

> Not revoking certificates will negate all the security of SSL.

Not true. The encryption part of the certificate is still there. However, the added assurance that you're really on the site you think is compromised.

But has the assurance part of SSL certificates actually reduced phishing? Stupid people will still put all their money in BankOfShmamerica.com as long as it looks sort of like the BankOfAmerica.com site and doesn't throw any errors.

If you think "the encryption part of the certificate" is still there, you don't really understand how SSL works. Without a secure certificate, you can't trust your SSL session keys. See:

http://news.ycombinator.com/item?id=277284

"the encryption part of the certificate" is still there as far as the wifi packets leaving your laptop are concerned, and as far as the poorly/maliciously configured linux router in the backroom of the coffee shop are concerned.

So, is it 100% secure? No. Is there still a reasonably high barrier of entry to getting your CC number/bank login? Yes.

That's like saying if you were using one of the weak Debian ssh keys, you might as well be using telnet. It's simply not true. The effort to steal your info is at least an order of magnitude (if not more) higher, even with weak ssh keys. The same situation applies here.

tptakec is 100% correct, but I like to explain stuff to people:

The packets leaving your laptop are protected from being eavesdropped by third parties, but the party you're sending your banking password to is some asshole who now apparently runs a CA, and just issued a certificate telling your web browser he's your bank.

The scenario under discussion (at least I as understood it from this particular thread of comments) is if we don't revoke all the compromisable certs. The scenario is NOT that I am connected to an attacker who has successfully used this attack against me.

Under that scenario, then you've already lost your data (although I'd still hold it's better to have your CC stolen by one person, rather than two), so yes, that's bad. However, that's not the scenario that I've been discussing here. This thread came under the debate about the risks and issues with revoking all those certs immediately, versus not.

If you're saying, "we shouldn't do anything rash to mitigate an attack that requires Arjen Lenstra and a specially tuned cluster of PS3s to accomplish", then that makes sense.

If you're saying, "we shouldn't do anything rash because certificates don't break encryption, only authentication", then you are perpetuating a really dangerous myth about SSL security.

You made the same point a few minutes ago, and I replied to it; long story short, you're not correct.

You're right - I've never implemented SSL, and as such don't know the minutia of the algorithm.

I didn't gather a lot of information from the link you posted, but this doc on the SSL handshake ( http://docs.sun.com/source/816-6156-10/contents.htm ) to my eyes doesn't show why you wouldn't be able to trust your session keys.

Could you explain how session keys can be compromised?

It doesn't make a difference whether the communication is encrypted if you can't verify with whom you are communicating.

That's decidedly untrue.

In this case I could be falling for a fake site and sending them my CC data, instead of Amazon, however I'm still protected from my CC being stolen by guy who setup the coffee house Wifi router.

Unfortunately, you too are misunderstanding how SSL works. If you own the coffee house WiFi router, you can decrypt any SSL session that traverses your network that doesn't use valid certificates. You simply need to inject your own certificate into the SSL session and fix a session key.

You cannot secure a conversation between two unrelated parties over the Internet without some form of authentication, to "break the tie" if the attacker presents their own keys/certificates.

Actually, I'm not.

I have great respect for your security knowledge, but your consistent black & white views and your assumption that anyone who doesn't share them doesn't understand the technology is frustrating.

If I own a coffee house router, or if I am simply sniffing un-encrypted wifi packets out of the air in the coffee house, logging traffic is extremely simple. I can log all traffic, or just traffic to http pages with names like login, or checkout, and I can do that very very very easily. It will log tons data automatically, and let me comb through it later. As a newbie to linux I could do that. The barrier preventing me from stealing the info you send over http is VERY low, and virtually anyone can do it.

The attack you describe is much more difficult to execute. The number of people who could make that attack is several orders of magnitude smaller than the previous attack. Hence my risk is several orders of magnitude smaller.

You're arguing that because skilled safe-crackers can open a safe, people should just leave their valuables on their lawn chairs out front. Security isn't black and white. Nothing will be 100% secure from every type of attack. It's a matter of raising the barrier of entry for an attack high enough that it's generally not worth the trouble.

What you're not acknowledging, anywhere in the above 5 paragraphs of text, is that all the security you're talking about getting from SSL in this scenario is security that the attacker is choosing to give you. When we reason about information security, we don't usually give the attacker that kind of advantage.

There is no such thing as a purely-passive attacker. In reality, no serious attacker is even going to bother sniffing your traffic; they're going to redirect it.

Sorry, the scenario we're talking about here, as laid out by you: "Not revoking certificates will negate all the security of SSL."

We're not talking about the scenario where a very smart attacker is targeting me with this security hole. We're talking about the impact of not revoking the certificates in question. At which point there is a very very small possibility that I will be targeted by an active attacker with the know-how to exploit this issue. The rest of the time SSL will continue to work as designed and will protect me from wifi snoopers and suspect routers.

There absolutely are passive attackers. There are people running open wifi points that log http form submissions with a "password" field, and then try the same username/password on a few major sites (ebay, amazon, etrade, gmail, BoA, etc...) automatically (working on the assumption that people use the same login/password on the many non-ssl authed non-important sites as they do for their important accounts). Successful login data is marked. I have met people running these. It costs nothing, is fully automated, and has very little risk.

They may not be "serious attackers", but the likelihood of one of them getting your mom's eTrade info is much higher than an active attacker targeting your mom.

I'm sorry, I'm just not interested in talking about security in terms of attackers who are too dumb or lazy to carry out well-known, utterly practical attacks. You can keep saying that "the encryption part of SSL works fine with authentication"; if you add the phrase "as long as you're dealing with functionally retarded adversaries", I won't even call you on it.

Well known and utterly practical? You have been commenting about how difficult this attack is and how the MD5 collision breakthrough is still secret.

You're not interested in the risk of or protection against provided by SSL encryption for a simple and probably relatively common passive attack? Because those people are lazy or dumb, we can write them off entirely and say SSL provides no security if there's a potential CA related exploit? I get that it's not as interesting a situation to think about, but I think that logically you can prove that SSL provides an increased security over http to the end user, even if some certs could be compromised.

" (2) You have to be able to generate the collision within a short window of time to get the resulting product signed properly by the CA, so you need the new academic result (and the PS3s).

(1) The attack is extremely difficult to pull off.

(2) Critical details required to carry it out --- an academic breakthrough in MD5 collision-finding --- were actually withheld, meaning that no "zero-day" occurred. (3) The "fix" for this attack is for RapidSSL to randomize serials and stop using MD5, both of which will happen; if you believe certificates from before today are vulnerable, that's an even stronger argument for publishing. "

The attack you are talking about it completely trivial. It relies on you being too dumb to even care if you have a real certificate. The attack Sotirov, et al have discovered is extremely hard. It works even if you check certificates.

I think that was modoc's original point, in response to the 'stella' comment. SSL, even if vulnerable to Sotirov-level impersonation attacks, still protects from other idiot-level attacks.

So you might be tricked into setting up encrypted communication to one of the (small) N groups that have the knowledge/budget to do a Sotirov attack, but at least you still won't have identity details hijacked by (large) M others, because even broken cert-checking protects against them.

whew wipes brow

Exactly! I'm sorry I wasn't communicating clearly enough.

You were.

Out of all the hypothetical scenarios you could have chosen, you picked one where it is not only possible to intercept your encrypted data but really quite obvious how to do it.