Closed Bug 1076440 Opened 10 years ago Closed 9 years ago

temporarily certificate exceptions are still accepted, even when the certificate has been removed within the manager

Categories

(Core :: Security, defect)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 660749

People

(Reporter: calestyo, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 Iceweasel/32.0.3
Build ID: 20140925082140

Steps to reproduce:

Maybe this is not a bug in NSS itself, but rather how it's used, but then it applies to all the other Mozilla Products (FF, Thunderbird). This was at least tested with FF 32.0.3 and NSS 3.17.1

When a certificate is exceptionally accepted temporarily, one can use the respective TLS/SSL service (e.g. a website).

When one then explicitly deletes the temporary certificate from the server tab in the certificate manager, it is however still accepted.

This is quite a severe security violation, cause when one explicitly deletes the certificate (in contrast to just restarting the browser at some time) one really wants to distrust this certificate.
Mozialla products however still continue to use it.
Severity: normal → major
Component: CA Certificates → Libraries
Component: Libraries → Security
Product: NSS → Core
Version: 3.17.1 → Trunk
This might be caused by bug 660749 (i.e. not re-validating certificates when loading from the cache). Christoph, if you use shift-reload (this clears the cache) after you've removed the override, do you see the expected certificate error?
Flags: needinfo?(calestyo)
Jep, you're right, this is the case.
With ****-Reload it works correctly.



I didn't even know that "normal reload" isn't a real reload (although this would explain many odd errors in FF o.O
To be honest, this behaviour of reload just sounds another bug, which is actually not less severe.
Imagine I reload my security.debian.org, trying to get most recent vulnerability infos, and it actually does *not* reaload.

Who decided about that behaviour, and has he gotten his commit rights already removed for life? o.O
Flags: needinfo?(calestyo)
(In reply to Christoph Anton Mitterer from comment #2)
 
> Who decided about that behaviour, and has he gotten his commit rights
> already removed for life? o.O

No personal attacks on Bugzilla, please. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Well sorry, but these are all quite serious issues. Sure none of this is a buffer overflow or broken parsing of ASN.1 which lead to whatever scary stuff which we've seen in the past.
But these are higher level attack vectors, which are not less scary.

It's like social engineering: you don't need to find some security hole in openssh to get into people's systems - most of the time it's much easier to somehow "socially" attack them and get the pasword directly.


That's what we have here, or at #1079581 or maybe even with #1078764,... none of them is the typical security hole... but all of them clearly break things one would definitely expect.
In this bug, "when I click reload, I expect that everything is really reloaded - and not from some cache, or the archive.org".

When these most basic expectations don't work however, one can easily run into circumstances which also mean that one's security is compromised, even if it's "just" on a higher level, like my example above, that one reloads his vendor's security website, but never gets notified about critical update, because Mozilla does stupid things.


Now it appears that such issues aren't just "mistakes" or "accidents" - they're clear design decision made by some developers, clearly ignoring what should be highest priority (security of their users), apparently rather looking into stupid things like "we want a bigger market share, and therefore FF needs to reload 5ms faster than other browsers".

And yes, it's no doubt a thread, if people who deliberately made such positions (not just accidentally) stay in their positions, cause when there's the next thing to decide about security vs. speed, or security vs. "coolness", or security vs. money/market share,... they'll again kick security in the bin.


Now the really outrageous part is, that even when people notify Mozilla about such issues, all you get is more or less things like over at #1079581 "yeah,... we break standards... but well we're Mozilla and we can do this if we want".
So please bear with me, if my politeness has suffered a bit.

Apart from that, I didn't "attack" anyone *personally*,... since I didn't look up who made this decision and from "John Doe should have his commit rights rescinded" - and even if I would, this is probably not yet an attack, is it?
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.