Mozilla Says It Erred On SSL Attack Disclosure

← Back to Stories (view on slashdot.org)

Mozilla Says It Erred On SSL Attack Disclosure

Posted by Soulskill on Friday March 25, 2011 @07:17AM from the comodo-draggin-their-feet dept.

Trailrunner7 writes "Just days after news emerged of the attack on a registration authority in Europe tied to Comodo that caused the revocation of a number of fraudulent certificates from the major browsers, Mozilla officials have admitted they made a mistake by not disclosing the details of the incident to its users earlier. 'In hindsight, while it was made in good faith, this was the wrong decision. We should have informed web users more quickly about the threat and the potential mitigations as well as their side-effects.'"

62 comments

Min score:

Reason:

Sort:

In other words by killmenow · 2011-03-25 07:22 · Score: 0

D'OH!
What can users do about it by paultwang · 2011-03-25 07:24 · Score: 1

when there is no other widely accepted way to verify a website's identity.
1. Re:What can users do about it by taktoa · 2011-03-25 07:26 · Score: 0
  
  when there is no other widely accepted way to verify a website's identity.
  Well, one could just not go on the internet, but I suppose that's not an option given that you're posting on /.
2. Re:What can users do about it by Anonymous Coward · 2011-03-25 07:28 · Score: 0
  
  You can do the same thing they did, and add the issuer to the revocation list.. (Tools, Options, Advanced, Encryption, Revocation Lists)..
3. Re:What can users do about it by Anonymous Coward · 2011-03-25 07:37 · Score: 0
  
  But we don't need several hundred CAs (including, for example, the Turkish security services). It would be nice if Firefox had a simple way to disable them all by default and let you re-enable just the few you thought were actually trustworthy (or, at least, not entirely untrustworthy). At the moment you have to open a dialog box for each certificate, click on a few check-boxes, click OK and move on to the next one. And you can't see which are disabled and which aren't, making it very hard to deal with new CAs.
  Does anyone know if there's a better tool to manage Firefox's cert8.db?
4. Re:What can users do about it by rb12345 · 2011-03-25 07:39 · Score: 1
  
  Removing or disabling the affected CA in the browser would be a simple enough workaround in this case, although you'd then have to trust individual certificates by hand. If previously seen certificates could be trusted directly, without fully trusting the CA, that would be even better. For example, I could trust that the existing Google certificates are good, but no longer trust the CA certificate that signed them.
  You'd probably want separate levels of trust, so that certificate revocations would still be valid. That would still allow possible DoS if the CA certs were compromised, but that's still an issue now.
5. Re:What can users do about it by freakingme · 2011-03-25 07:39 · Score: 2
  
  There's DNSSEC, which more and more ISP's and registries support. Then, if someone managed to hijack a certificate he/she would also have to spoof google's IP.
6. Re:What can users do about it by Anonymous Coward · 2011-03-25 07:46 · Score: 0
  
  Yeah. Ditch Firefox for a browser that respects the OS certificate store
7. Re:What can users do about it by Anonymous Coward · 2011-03-25 07:47 · Score: 2, Insightful
  
  Why is a US based CA inherently more trustworthy than one from Turkey? Fact of the matter is, TURKTRUST has a perfect security record, while Comodo is just the latest in a long line of breaches of US CAs. And even if that wasn't the case, it's still completely irrelevant to this breach. You can't possibly claim that a major browser should not have Comodo enabled by default, unless you're making the asinine claim that no CAs should be enabled by default.
8. Re:What can users do about it by WaffleMonster · 2011-03-25 07:53 · Score: 2
  
  There's DNSSEC, which more and more ISP's and registries support. Then, if someone managed to hijack a certificate he/she would also have to spoof google's IP.
  Here here! The difference the CAs will tell you is they verify and identify the organization rather than the domain name...
  Poser = "mcdnalds.com"
  Ronald = "mcdonalds.com"
  The reality seems to be more CAs continue to make the process easier and easier to increasingly enrich themselves without having to do much to show for it in return... Now many offer a completely automated process to instantly obtain a cert...WTF?!?!?!
  In my view the system would be better off if we all got SSL certs with our DNS names and then come up with a process where CAs shift exclusivly to verification of identity.. such that access to mcdnalds.com and mcdonalds.com is secure however the user would also know through a browser display that mcdonalds.com has been verified as belonging to Ronald while mcdnalds.com has not.
9. Re:What can users do about it by 0123456 · 2011-03-25 07:54 · Score: 1
  
  Comodo is a British company, isn't it?
10. Re:What can users do about it by Anonymous Coward · 2011-03-25 07:56 · Score: 0
  
  The problem isn't what Firefox does by default. The problem is that if you don't like the default, the UI is completely inadequate for managing the several hundred built-in root certificates.
  P.S. I've disabled Comodo and it has caused me no problems at all. Does any major site use it?
11. Re:What can users do about it by maxwell+demon · 2011-03-25 08:02 · Score: 1
  
  I don't think the point is specifically the trustworthyness of TURKTRUST, but that it's an example of a certificate which likely is completely useless for him, just like a plethora of other such certificates, all of which are trusted by default. If any of those is broken, you are vulnerable by default. If you enable only those which you actually use, your vulnerability is greatly reduced.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
12. Re:What can users do about it by Anonymous Coward · 2011-03-25 08:06 · Score: 0
  
  Here here!
  Try applying logic, and think about this expression once more.
13. Re:What can users do about it by WaroDaBeast · 2011-03-25 08:18 · Score: 1
  
  Beat me to it. It all goes back to "Hear ye, hear ye," of course.
  
  --
  "The body may heal, but the mind is not always so resilient." -- Deus Ex: Human Revolution
14. Re:What can users do about it by heypete · 2011-03-25 08:45 · Score: 4, Informative
  
  You can also not bother using CRLs, and just use OCSP, which is turned on by default (EV certificates require it or else the browser won't display the "green bar").
  As it does live checks on only the certificates presented right then, rather than downloading the whole CRL at intervals, OCSP uses less network resources for both you and the CA, updates faster (CRLs update every few days), and is generally superior in all ways. Like CRLs, OCSP responses are signed by the CA that issued them, and so cannot be tampered with.
  You can even have your browser set to not trust the certificate presented if the OCSP query fails, which is a good fail-safe. I wish there was a "warn if OCSP check fails" option, rather than "fail silently and allow connection to proceed if OCSP fails" and "fail noisily and not work if OCSP fails". The former leaves people vulnerable, while the latter presents DoS attack targets.
  Pushing out OS and browser updates to manually revoke those certificates is not a bad idea, particularly for those who have OCSP disabled for whatever reason, but there's not really any reason to manually install CRLs when OCSP exists.
15. Re:What can users do about it by UBfusion · 2011-03-25 08:52 · Score: 1
  
  As I write, Turkey has 305,678 FF4 downloads, many more than most EU and ex-USSR countries. Also it is a major US military ally, which adds to the need for trust by default.
  If you look at the pending certificates page of Mozilla you'll see that getting that an approval is a slow, painful (due to the bureaucracy needed) and expensive (due to the need for major lawyer firms getting involved) matter. For example, visiting Mozilla headquarters and saying "I am the president of country/corporation X, please add my root CA" does not work.
16. Re:What can users do about it by Anonymous Coward · 2011-03-25 11:42 · Score: 0
  
  How about we cut out the middle man and just put the public keys (certificates) in the DNSSEC records for the domain itself. The whole point of DNSSEC is that it has a chain of trust, so I don't see the need for CAs at all once that comes to pass.
17. Re:What can users do about it by BZ · 2011-03-25 15:15 · Score: 1
  
  The problem is that OCSP as currently implemented doesn't really work, precisely because of the two problems you describe (vulnerability if OCSP checks are nonfatal, failure to connect if they are). In fact, there are places where all OCSP is effectively blocked (airport wireless networks before you've paid, say, and paying requires SSL, so if OCSP is fatal then you can't pay). As a result, browsers default to non-fatal OCSP checks (with Chrome having a small unobtrusive warning if the check fails, which I fully expect that users ignore).
  The warning approach would work for you, but not for most people, who have no idea what OCSP is or what to do with a warning about it, unfortunately. Either the warning would be unobtrusive and missed or look like an error page kinda thing, and confuse people...
18. Re:What can users do about it by maxwell+demon · 2011-03-25 22:15 · Score: 1
  
  No one said Mozilla should not offer that certificate for those who need it. They can even install it on the browser for one-click enabling. However what they should not do is enable it by default.
  Ideally, when you first visit a site for which Mozilla has a root certificate but it's not enabled, it should tell the user what certificate it is, and if he wants to enable it (without a big, scary security warning, just "this site uses a certificate issued by TURKTRUST; the root certificate is available, do you want to enable it?") Then if it's a Turkish site, I'll just enable the certificate, while if it's Yahoo, I'll conclude that it's likely compromised and don't enable it.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
19. Re:What can users do about it by Anonymous Coward · 2011-03-26 02:15 · Score: 0
  
  Not a major site, but https://www.eff.org uses Comodo CA as I found out when I also removed the trust bits from its certs. Haven't come across any other sites using them yet.
20. Re:What can users do about it by jd · 2011-03-27 06:53 · Score: 1
  
  The extent of the problem is surely a matter of whether the signing key was obtained or not. If the attackers obtained that, then revoking the certs issued on the CA's computer are almost immaterial as the attacker can continue issuing certs on their own computer. Gah, this is such a mess.
  
  --
  It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
21. Re:What can users do about it by jd · 2011-03-27 19:04 · Score: 1
  
  You still want verification of the actual details, that the individual authorized for the cert is the one authorized to have the website, ad nausium, but your idea is excellent.
  Ok, how about this:
  A DNS site's certificate has to be master-signed by a CA at level 3 trust (since it's infrastructure we're talking about) and then has to be counter-signed by one or more of the upstream DNS suppliers. This combines the web of trust with a superskeleton of validation that is independent of the web of trust. Compromising one or the other won't allow for fake certs.
  An IPSec tunnel would do the same (again, it's infrastructure), but would get counter-signatures from each of the DNS vendors supplying the A record for each endpoint. Not sure what to do about MPLS.
  A website does the reverse. It must be master-signed by an upstream DNS supplier (the one holding the information on who owns that record would do nicely) and then counter-signed by a CA at level 2 at minimum, level 3 for anything corporate. Again, dual keys making it harder to compromise any given organization.
  DNS servers, IPSec tunnels and web browsers must positively validate all signatures present as being correct and from public keys that are not revoked AND positively validate the cert is not itself classed as revoked before validating the cert as correct.
  Note that "positively". The system should be fail-safe. Revocation lists should be widely distributed and effectively impossible to block, but if a machine cannot reach any locatable revocation list (service location protocol is your friend, as is anycasting) then the cert should be disabled rather than assumed valid.
  SASL2 should be implemented in browsers and should be used when it would be more appropriate than SSL/TLS.
  Certain network regulations should be introduced (or re-introduced). Level 2 certs should be the lowest standard acceptable from any public CA. Level 1 should be strictly kept to roll-your-own sites. Level 3 should be mandated as the minimum for eCommerce or other "Commercially Confidential" information. No cert should EVER use RC4, MD5 or any other hash certified as broken for ANY part of the process, even with roll-your-own. That should be banned. A copy of the Hash Lounge with the SHA3 lounge added on should be kept in XML form at standard locations. Hashes with no known breakage are good for level 1. Hashes with no known weaknesses to any extent are good for level 2. Hashes that are compliant with the latest FIPS180 are good for level 3. (That means level 2 security may be better, but level 3 has better trust, which is what level 3 is about.)
  DNSSEC (although I'll agree there's better DNS security mechanisms out there) should be mandated. Well, except where the better DNS security mechanisms exist and there's a decent bridge between the two.
  ISP-to-ISP (ie: not host-to-host or server-to-server) connections should be over IPSec. Where the IPSec connection is not ad-hoc, digital certificates or other means of proving endpoint and tunnel validity should be used. (The user won't necessarily know or care.)
  You've now got a validated set of ingress and egress points to reach the destination, the destination is doubly validated (hostname and website name) and a validated tunnel to go from start to finish if it's supposed to be a permanent link*, where none of the authentication has a single-point-of-failure that can be exploited. Is that or is that not a secure system?
  *In real-world terms, you validate the start and end points of a cab ride, but not the company. If you're going by air, you validate the end-points, the carrier, and everything else you can imagine. This is the difference between ad-hoc and a permanent/semi-permanent link.
  
  --
  It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
22. Re:What can users do about it by Anonymous Coward · 2011-03-28 06:07 · Score: 0
  
  It would be nice if Firefox (and the other browsers) displayed who signed the certificate for the site you are visiting, then if the signing CA changed you might want to check it out. The default browser on the N900 does this by way of a banner that pops up for a couple of seconds when you visit a secure site. It is such a simple thing that could make a real difference in helping a user spot MITM attacks where the attacker had somehow got a valid certificate that it made me wonder why I'd never seen it on browsers before.
23. Re:What can users do about it by heypete · 2011-03-29 08:38 · Score: 1
  
  That's why it's a good idea to have an offline root certificate that is only used for signing one or more intermediate issuing certificates. These intermediates then sign certs issued to the public.
  If the intermediates get compromised, the root is brought out of storage, issues a revocation for the intermediates (which also revokes any keys issued by the now-compromised intermediate), signs a new intermediate, and is put back into storage. This greatly reduces the risk of the root being compromised. Since roots can't really be revoked (short of having the browsers remove them), keeping the roots offline and using intermediates results in a less-catastrophic failure mode.
No harm, no foul by multipartmixed · 2011-03-25 07:29 · Score: 1

I don't see what the big deal is. Everybody knew about this vulnerability as soon as Microsoft told them about it anyhow.

--

Do daemons dream of electric sleep()?
1. Re:No harm, no foul by Anonymous Coward · 2011-03-25 07:32 · Score: 3, Insightful
  
  Yeah except if the situation had been reversed and Microsoft had done what Mozilla did. Then there would be pitchforks about how Microsoft was being evil. But, no, this time it was Mozilla and they can just do no wrong.
2. Re:No harm, no foul by andrea.sartori · 2011-03-25 07:47 · Score: 1
  
  Yet apparently they say they can.
  
  --
  Mostly harmless.
3. Re:No harm, no foul by Anonymous Coward · 2011-03-25 07:48 · Score: 0
  
  Except Microsoft was involved here too?
4. Re:No harm, no foul by bmuon · 2011-03-25 07:50 · Score: 0
  
  Yeah except if the situation had been reversed and Microsoft had done what Mozilla did. Then there would be pitchforks about how Microsoft was being evil. But, no, this time it was Mozilla and they can just do no wrong.
  If Microsoft had been honest and reflected openly about its mistake, then there wouldn't have been any pitchforks. Although it is true that lots of developers are partial against Microsoft, it is also true that they have been welcoming when MS made good decisions. Take a look at the response from the community about IE9. It was critical in specific aspects, but overall very happy with the change in relationships (they started with very early previews) and product quality.
5. Re:No harm, no foul by hedwards · 2011-03-25 07:51 · Score: 0
  
  It's fundamental different when it's an isolated incident versus the standard operating procedure. MS wouldn't be getting anywhere near as much crap if it was just one vulnerability from time to time as they now that it's pretty much every vulnerability.
  Plus, MS doesn't typically admit screwing up for doing it either.
6. Re:No harm, no foul by UBfusion · 2011-03-25 09:09 · Score: 1
  
  Since you seem to know the internal workings of MS, have they ever issued a patch to remove fraudulent or "defective" root CAs? Is any of those hundreds of OS updates I have on my PC SSL-related?
7. Re:No harm, no foul by Gadget_Guy · 2011-03-25 14:42 · Score: 1
  
  They have another system in place to handle certificate revocation. You can enable/disable this in IE in "Internet Options->Advanced->Security". I believe Safari and Chrome also use this OS level certificate handling too.
8. Re:No harm, no foul by UBfusion · 2011-03-26 02:35 · Score: 1
  
  +1 informative, thanks!
Oooh, Europe by Anonymous Coward · 2011-03-25 07:52 · Score: 0

That was an important detail, right? That it wasn't Comodo but some European registration authority, whatever that is supposed to be. Except Usertrust, the culprit, has a Comodo logo sitting right at the top of their web site, and "Comodo Home" and "About Comodo" links to go with it. Don't kid yourself, this was Comodo.
1. Re:Oooh, Europe by andrea.sartori · 2011-03-25 07:55 · Score: 1
  
  "some European registration authority tied to Comodo." I won't go as far as to say you should RTFA, but I don't think the first line of the summary is too much to read.
  
  --
  Mostly harmless.
2. Re:Oooh, Europe by Anonymous Coward · 2011-03-25 08:04 · Score: 0
  
  Except it is not "a registration authority in Europe tied to Comodo". That phrase is intentionally misleading by giving the impression that the incident was the fault of someone other than Comodo. The brand is "Comodo Usertrust". This incident happened at Comodo, not someplace that is just "tied to Comodo".
some protection by Onymous+Coward · 2011-03-25 08:10 · Score: 1

Have your browser monitor for when certs are updated. And use public notaries to tell you whether others are seeing the same certs for the site.
Certificate Patrol
Perspectives
An example of who else is seeing the addons.mozilla.org cert you're seeing.
Comment removed by account_deleted · 2011-03-25 08:15 · Score: 1

Comment removed based on user account deletion
Plug by Anonymous Coward · 2011-03-25 08:19 · Score: 0

On a positive note, you know what service I found that had a very good track record on this? Tarsnap.
It's a backup service I use. The client compresses and encrypts data on your end before sending it to the server, and the client isn't open-source, but it is source-viewable in the sense that you can download, inspect, and build the source yourself. All in all, great security - even from the provider.
Then one day a couple months ago I got an email from the provider warning that he had been alerted to a vulnerability. I was notified the same day as the provider, a fix was available that day, and there was an explanation of exactly what should be done to mitigate any breach that may have already been made. It was, in short, exactly what I would have wanted a service provider to do.
If this provider (which seems to be a one-man show) can pull this off, then I think we should expect it of the big boys.
Are you nuts? by UBfusion · 2011-03-25 08:36 · Score: 1

Do you really imply that an OS made by a Corporation is more trustworthy than an .org like Mozilla? Are you perhaps living behind The Walled Garden?
1. Re:Are you nuts? by Anonymous Coward · 2011-03-25 09:10 · Score: 1
  
  No, I said the tools for managing OS certs are better (on all OSes). But yes, the OS store is more hardened from attack. And it makes no sense to have multiple dbs. Microsoft's update blocked their use in all compatible programs (Safari, Chrome, IE, etc). Aside from that, it's kind of embarrassing that Mozilla resorted to hardcoding the ids, rather than editing the configs or pushing the bad certs across.
  Anyway, a program is only as secure as the OS it's on, so your post is absurd even disregarding the above.
2. Re:Are you nuts? by Anonymous Coward · 2011-03-25 13:21 · Score: 0
  
  By that definition, a Windows program can never, ever be secure. We probably all knew that already though.
3. Re:Are you nuts? by Anonymous Coward · 2011-03-25 14:42 · Score: 0
  
  Accurate enough I guess, but it would probably be better to say that no program can be more secure than the OS it's on.
Good on them by BlueParrot · 2011-03-25 08:46 · Score: 4, Insightful

Admitting it was a mistake rather than coming up with some bogus excuse gives them points in my book. Whether the decision was by marketing or just company policy it at least suggests they have one or two competent people over there.
1. Re:Good on them by cerberusss · 2011-03-25 23:23 · Score: 1
  
  Admitting it was a mistake rather than coming up with some bogus excuse gives them points in my book.
  I agree, however they should also be open about the punishment given to those responsible. A lethal SQL injection perhaps?
  
  --
  8 of 13 people found this answer helpful. Did you?
Re:I must just be dumb, because I don't get it by Anonymous Coward · 2011-03-25 09:05 · Score: 0

your bank could sign it's own certificate, burn it onto an 80mm cd, then give it too you when you sign up for a bank account.
Now to perform a mitm attack you have to become a customer service rep at the bank branch of your intended victim.
Re:I must just be dumb, because I don't get it by UBfusion · 2011-03-25 09:06 · Score: 1

I'm not a security expert and my crypto knowledge is limited. But from what I can understand, the general principle here is that trusting somebody unknown is considered more dangerous than not trusting somebody you know. In addition, the meaning of "trust" in the SSL context is that "you can trust me that anything that happens between me and you is encrypted, will stay between you and me, and nobody else can hear us". It's not "trust me, visiting my website won't harm your computer or your person". There has to be a way to ensure that your are using your Bank and not a fraudster or zombie system. SSL may not be perfect (considering it's several decades old) but it's a first step.
By the way, accepting a certificate by clicking OK is the equivalent of putting your signature on that site's terms of usage, not the other way around. So we'd better all read and learn more about it, it's not Mozilla's or the operating system's responsibility to teach us about it.
Not so open after all... by v(*_*)vvvv · 2011-03-25 09:13 · Score: 1

Why is everyone so afraid of being open? Maybe it's just part of the human condition.
We have little hope if even Mozilla leans towards nondisclosure.
1. Re:Not so open after all... by jd · 2011-03-27 06:16 · Score: 1
  
  Few things that are supposed to be "human condition" really are. That's usually just an excuse to not dig deeper. In this case, Mozilla happened to "err" on the side of non-disclosure just about the time it was releasing a new browser and really didn't need people mistaking the messenger for the message. Far better to let people worry about the security of other browsers.
  
  --
  It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I think they did the right thing - BOTH times by darthcamaro · 2011-03-25 09:15 · Score: 3, Insightful

Mozilla was the first browser vendor to patch. SURE they could have told us exactly what they were patching, but they erred on the side of caution. The fact that they want to be OPEN about everything is just a bonus and it's what differentiates Mozilla from every other browser vendor.
1. Re:I think they did the right thing - BOTH times by trifish · 2011-03-25 19:01 · Score: 3, Informative
  
  You didn't get what they did wrong. The knew about the issue 10 days before they disclosed it (and they were in fact forced to disclose it by a blogger). During that period, the affected unsuspecting people in Iran may have been exploited, snooped, arrested and/or executed. That's what they apologized for just now. But apologies won't help those victims (if there are any) a bit.
2. Re:I think they did the right thing - BOTH times by jd · 2011-03-27 06:24 · Score: 1
  
  This has been debated endless times, as to when it is best to reveal that a vulnerability exists, with one camp arguing that it's best to delay announcements until there is no risk that the announcement will increase the degree of exploitation, and the other arguing that unannounced exploits are ALWAYS a danger, that you should not assume that those who are potential threats are ignorant simply because the users are.
  As you can probably gather, I tend to be in the latter group. It doesn't take a child long to figure out that whether they can see you has no bearing on whether you can see them. Why it takes security experts well into their adulthood to figure that out (and some never do) is beyond me.
  
  --
  It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
3. Re:I think they did the right thing - BOTH times by Anonymous Coward · 2011-03-27 07:05 · Score: 0
  
  In this case there was absolutely no reason to keep it secret. Those who had the fake certs were the only ones who could have exploited it. A no brainer. It shows how amateurish the Mozilla people are. They really have a lot to apologize for!
4. Re:I think they did the right thing - BOTH times by jd · 2011-03-27 07:20 · Score: 1
  
  You are absolutely correct and I'd extend that to say that since we don't know if the attackers were able to obtain the master signing key or not (that key was not amongst the revoked), the risks caused by the embargo could be far worse than is currently known.
  
  --
  It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Re:I must just be dumb, because I don't get it by Anonymous Coward · 2011-03-25 11:16 · Score: 1

SSL seems fundamentally broken because it is.
Say a site devoted to dissidents, purchases a cert signing from some CA like Verisign.
Now, say your government, someone else's gov't, or some random corp has its own CA that is trusted by your browser. This government/corp wants to spy on your activity, so they gen a cert for dissidentsRus.org, and setup a transparent proxy to intercept your traffic. While they are at it, they setup the same for your bank.
Now, you visit dissidentsRus.org, and nothing looks odd on your browser, but your "encrypted and secure" traffic is being intercepted and unecrypted, in real time by some random gov't or corp. While they are at it, they decide to drain your bank account, since they were able to sniff your credentials the same way.
Yes, gov'ts and random corps run CAs that are trusted by the major browsers, so every time you use SSL, you are trusting _ALL_ these random corps and gov'ts that they are not trying to intercept your traffic.
As recent events demonstrated, the attacker doesn't even need to control the CA. Just rely on good 'ol social engineering and start siphoning bank accounts. Combined with DNS poisoning, and you can attack random folks anywhere you please.
requestpolicy extension for firefox helps to mitigate, but we really need something better than the trust model of SSL for asserting identity and encrypting traffic, that the mainstream can use.
Comment removed by account_deleted · 2011-03-25 13:48 · Score: 1

Comment removed based on user account deletion
Jacob Appelbaum by zugurudumba · 2011-03-25 19:11 · Score: 1

Most of this has been the work of Jacob Appelbaum, core member of the Tor project. He is the one who investigated the fraudulent certificates and it's a fascinating detective story.

--
Sig
I guess ... by Anonymous Coward · 2011-03-25 20:30 · Score: 0

... someone's not going to be told in advance next time. :-)
Re:I must just be dumb, because I don't get it by amorsen · 2011-03-25 22:49 · Score: 1

SSL is fundamentally broken. It only allows one signature of a certificate. If it allowed multiple signatures, anyone could sign the certificate, and you could do stuff like check if your friends trust this certificate, or whether your bank does, and so on. Just like PGP/GPG.
Sensible sites would get their certificates signed by multiple authorities, and this would make it possible for browser users to disable e.g. Comodo certificates without losing access to a significant part of the WWW.

--
Finally! A year of moderation! Ready for 2019?