"Eric Rescorla" <[email protected]> wrote: > No, this isn't correct either. > > One root CA issued a single bad certificate for a single domain. That > CA has now corrected its practices.
Well, we *KNOW* of one. That doesn't mean there isn't more. > A second root CA issued a single CA certificate. This certificate has > invalid markers (it's way out of date) and the private key for that > certificate is known only to some small group of people. In effect, > they're a CA. As long as they behave properly (i.e., don't issue > false certificates), there's no problem. They said more than once that they *COULD* get a valid one as well, but they did a outdated one to not harm anybody. They still can create one that is NOT outdated. They said that about 3 times in the talk that it isn't limited to outdated keys and that they could create a valid one any time. > > Even one root cert is enough > > to kill SSL. > > Again, this isn't correct. If the CCC team ever starts issuing false > certificates > for real, the browser manufacturers will just blacklist it. It's > really quite straightforward. Oh, please, browsers are the most unimportant clients when it comes to SSL. Sure, not if you do banking etc., but you shouldn't do that online anyway. But clients like MUA, XMPP etc. don't have a blacklist sometimes. For example, I haven't found one in Gajim yet. And this is where there's far more private data. Compromising a mail account can cost existences sometimes. If you attended the talk on 25c3 where they talked about what may come in 2009, you will have noticed that cracked mail accounts have the highest worth on the black market, higher than credit card information. > And if you're on the same network with people who know about a remote > exploit in your machine, then you better not trust the software on > your machine. Sure, there never is complete security. But breaking each machine is *MUCH* more work than doing a MITM, which will effect multiple people at once. > Given that there has been a major break in both common > SSH and SSL implementations this year (the Debian PRNG bug), it's a > little odd to be complaining about how this particular issue, which > is extremely hard to exploit, is the end of the world for SSL. What do you mean when talking about a break in SSH? I don't know of any. Only that there were issues with using SSH in CBC mode. But the default is CTR. > Right. SSL is usable in a much wider set of settings than SSH. It's > those settings that are implicated by attacks on CAs. I didn't say that SSH is better because it provides less features. But in *MY* special case that I explained, it *IS* better, for *ME* ;). I'm not saying to replace SSL by SSH, that'd be nonsense. And I'm not saying to get rid of Key Chains in SSH and always verify the fingerprint either. -- Jonathan
signature.asc
Description: PGP signature
