Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mozilla Says It Erred On SSL Attack Disclosure

Soulskill posted about 3 years ago | from the comodo-draggin-their-feet dept.

Mozilla 62

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


What can users do about it (1)

paultwang (946947) | about 3 years ago | (#35615354)

when there is no other widely accepted way to verify a website's identity.

Re:What can users do about it (1)

taktoa (1995544) | about 3 years ago | (#35615392)

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

Re:What can users do about it (0)

Anonymous Coward | about 3 years ago | (#35615434)

You can do the same thing they did, and add the issuer to the revocation list.. (Tools, Options, Advanced, Encryption, Revocation Lists)..

Re:What can users do about it (4, Informative)

heypete (60671) | about 3 years ago | (#35616450)

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.

Re:What can users do about it (1)

BZ (40346) | about 3 years ago | (#35619620)

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

Re:What can users do about it (1)

jd (1658) | about 3 years ago | (#35631564)

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.

Re:What can users do about it (1)

heypete (60671) | about 3 years ago | (#35658236)

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.

Re:What can users do about it (0)

Anonymous Coward | about 3 years ago | (#35615590)

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?

Re:What can users do about it (0)

Anonymous Coward | about 3 years ago | (#35615700)

Yeah. Ditch Firefox for a browser that respects the OS certificate store

Are you nuts? (1)

UBfusion (1303959) | about 3 years ago | (#35616350)

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?

Re:Are you nuts? (1)

Anonymous Coward | about 3 years ago | (#35616742)

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.

Re:Are you nuts? (0)

Anonymous Coward | about 3 years ago | (#35618860)

By that definition, a Windows program can never, ever be secure. We probably all knew that already though.

Re:Are you nuts? (0)

Anonymous Coward | about 3 years ago | (#35619404)

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.

Re:What can users do about it (2, Insightful)

Anonymous Coward | about 3 years ago | (#35615702)

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.

Re:What can users do about it (0)

Anonymous Coward | about 3 years ago | (#35615816)

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?

Re:What can users do about it (0)

Anonymous Coward | about 3 years ago | (#35621830)

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.

Re:What can users do about it (1)

maxwell demon (590494) | about 3 years ago | (#35615900)

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.

Re:What can users do about it (1)

UBfusion (1303959) | about 3 years ago | (#35616546)

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.

Re:What can users do about it (1)

maxwell demon (590494) | about 3 years ago | (#35620838)

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.

Re:What can users do about it (0)

Anonymous Coward | about 3 years ago | (#35642462)

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.

Re:What can users do about it (1)

rb12345 (1170423) | about 3 years ago | (#35615620)

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.

Re:What can users do about it (2)

freakingme (1244996) | about 3 years ago | (#35615630)

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.

Re:What can users do about it (2)

WaffleMonster (969671) | about 3 years ago | (#35615766)

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.

Re:What can users do about it (0)

Anonymous Coward | about 3 years ago | (#35615950)

Here here!

Try applying logic, and think about this expression once more.

Re:What can users do about it (0)

Anonymous Coward | about 3 years ago | (#35618164)

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.

Re:What can users do about it (1)

jd (1658) | about 3 years ago | (#35635908)

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.

No harm, no foul (1)

multipartmixed (163409) | about 3 years ago | (#35615464)

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

Re:No harm, no foul (3, Insightful)

Anonymous Coward | about 3 years ago | (#35615520)

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.

Re:No harm, no foul (0)

Anonymous Coward | about 3 years ago | (#35615718)

Except Microsoft was involved here too?

Re:No harm, no foul (0)

bmuon (1814306) | about 3 years ago | (#35615740)

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.

Re:No harm, no foul (0)

hedwards (940851) | about 3 years ago | (#35615750)

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.

Re:No harm, no foul (1)

UBfusion (1303959) | about 3 years ago | (#35616730)

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?

Oooh, Europe (0)

Anonymous Coward | about 3 years ago | (#35615760)

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.

Re:Oooh, Europe (1)

andrea.sartori (1603543) | about 3 years ago | (#35615800)

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

Re:Oooh, Europe (0)

Anonymous Coward | about 3 years ago | (#35615928)

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

evile denies serious errors in math, history etc (-1)

Anonymous Coward | about 3 years ago | (#35615872)

isn't that a surprise? doesn't mean it isn't still happening?

creators; stand by for another fake big flash

again, it's not us. believe whatever you're told? It's ALL out of the
chosen ones manual/schedule/agenda/anal 'math' depopulation schemes etc..,
which is resulting in many of our innocents being vaporized, which is
'better' than many of the others' current 'fate'. for god's sakes?

best bets; everyone (on our planet) voluntarily disarm yourselves. carry
on as it was originally intended for all of us. we instinctively know what
that is.

highly wagered longshots; eugenatics, weapons peddlers, kings/minions,
genetically altered mutants/hired goons. media decepticons, adrians,
religiously infactdead groanups, fake weather/induced seismicity
'scientists' etc...

hold on to your equatorial equilibrium.

in the end...in the middle... & from the beginning, babys rule..-- wee key (diaper) leaks group, perishability & play-dates pending world disarmament

I must just be dumb, because I don't get it (1)

CarsonChittom (2025388) | about 3 years ago | (#35616090)

Can anyone explain to me why the whole SSL system isn't fundamentally broken in the first place? And by "fundamentally broken" I mean that it seems like trusting Certificate Authorities to vouch for people seems little different than trusting any random stranger.

On the other hand, of course, what choice do I have if I want to do something useful online? It's not like I can call up my bank president and make him pinky swear that if anybody sniffs my login credentials and steals all my money he'll reimburse me.

Re:I must just be dumb, because I don't get it (0)

Anonymous Coward | about 3 years ago | (#35616676)

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 (1)

UBfusion (1303959) | about 3 years ago | (#35616700)

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.

Re:I must just be dumb, because I don't get it (1)

Anonymous Coward | about 3 years ago | (#35617958)

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.

Re:I must just be dumb, because I don't get it (1)

CarsonChittom (2025388) | about 3 years ago | (#35619054)

This makes more sense than the parent. So either wisdom comes from anonymous cowards, or I'm paranoid; I'm not sure which.

Re:I must just be dumb, because I don't get it (1)

amorsen (7485) | about 3 years ago | (#35620912)

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.

Plug (0)

Anonymous Coward | about 3 years ago | (#35616146)

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.

WTF-Firefox really insecure because of certs!!? (-1)

Anonymous Coward | about 3 years ago | (#35616438)

Shouldn't this be the real title of this /. story.

Citrix was convinced to help defeat OSS not that long ago and that is why they made their clients choke on Firefox early in 2010.
Just before their big push to sell GO To My PC and how great it is to be able to easily do secure networking on Windows 7. All you have to do is turn on your TV and you see how MS.....NBC must be almost letting Citrix advertise for peanuts! How they can afford to advertise the heck out of a piece of software in prime time is a wonder to behold!

You do not have to worry about having dangerous FIrefox users using https to access your net with the Linux citrix ica client anymore. Of course if you just copy the certs to a different place then the citrix ica client will work with Firefox on either windows or linux.

I am coming to the conclusion that the networking giants like Citrix are starting to make it so you will have no choice in what operating system or browser you use to access Windows based servers...it is almost as if the coders at Citrix are really MS shills. Heck the new .deb ica client is a joke! It must have been cobbled together by an ex-microsoft employee!

So again I am being forced into buying a new copy of windows so my wife can do her work. The story has not change in 20 years. Use MS Office and Internet Explorer or you will not be able to do your work remotely or even read documents at home.

She used Firefox and Linux with Citrix safely for 4 years and now she is forced into using Internet Explorer because of changes to the location seek for certs in the Citrix clients. I am really getting sick and tired of being bullied by Microsoft and their "business partners".

They are getting away with all this shit because they are messing around again with compatibility on the net and no one is taking notice. It is obvious what is going on this time. Microsoft is in bed with Citrix and are trying to push Linux and Samba out the same way they are pressuring Motorola to drop Android, spreading fud on a mammoth scale and spending tons of cash to lobby Linux, Google/Android and many other competing networking software writers out of existence.

Being somewhat of a geek....and
To quote a famous rabbit..."you realise of course, this means war!"

Good on them (4, Insightful)

BlueParrot (965239) | about 3 years ago | (#35616468)

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.

Re:Good on them (1)

cerberusss (660701) | about 3 years ago | (#35620994)

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?

Not so open after all... (1)

v(*_*)vvvv (233078) | about 3 years ago | (#35616780)

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.

Re:Not so open after all... (1)

jd (1658) | about 3 years ago | (#35631346)

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.

I think they did the right thing - BOTH times (3, Insightful)

darthcamaro (735685) | about 3 years ago | (#35616828)

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.

Re:I think they did the right thing - BOTH times (3, Informative)

trifish (826353) | about 3 years ago | (#35620404)

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.

Re:I think they did the right thing - BOTH times (1)

jd (1658) | about 3 years ago | (#35631394)

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.

Re:I think they did the right thing - BOTH times (0)

Anonymous Coward | about 3 years ago | (#35631642)

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!

Re:I think they did the right thing - BOTH times (1)

jd (1658) | about 3 years ago | (#35631760)

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.

I guess ... (0)

Anonymous Coward | about 3 years ago | (#35620578)

... someone's not going to be told in advance next time. :-)

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account