Bug that hit Firefox and Tor browsers was hard to spot-now we know why
|
|
|
Comments (3)
@mbaehrlxer
> Free Software should not have a known expiry date...
I realize this isn't really related at all, but HP's (Free? non-free?) Firmware has an expiry date that is DECIDELY preventing bona fide HP printer owners from using cheaper third-party ink cartridges! http://arstechnica.com/information-technology/2016/09/hp-sho...
$heesh, what an incredibly lousy M$-like tactic!!
2c
> Free Software should not have a known expiry date...
I realize this isn't really related at all, but HP's (Free? non-free?) Firmware has an expiry date that is DECIDELY preventing bona fide HP printer owners from using cheaper third-party ink cartridges! http://arstechnica.com/information-technology/2016/09/hp-sho...
$heesh, what an incredibly lousy M$-like tactic!!
2c
@mbaehrlxer:
It seems the vulnerability discussed in the article is two pronged and specific to the Mozilla add-on site.
Both the Mozilla add-on site and the Mozilla client browser needed updating. The Mozilla add-on site was doing 'pinning' but, apparently, not per specification. And, I guess, the Mozilla browser was written to accommodate the 'incorrect' pinning... which led to a security vulnerability when Mozilla's server pins {and only Mozilla's pins} expired.
I guess... it's somewhat difficult to understand the whole issue at first reading.
***
My personal opinion of 'pinning' is that it's security done wrong to begin with... If your server has been compromised, so have your pins. A better way would be to put a public key in DNS and protect the DNS entry via DNSSEC.
Both the Mozilla add-on site and the Mozilla client browser needed updating. The Mozilla add-on site was doing 'pinning' but, apparently, not per specification. And, I guess, the Mozilla browser was written to accommodate the 'incorrect' pinning... which led to a security vulnerability when Mozilla's server pins {and only Mozilla's pins} expired.
I guess... it's somewhat difficult to understand the whole issue at first reading.
***
My personal opinion of 'pinning' is that it's security done wrong to begin with... If your server has been compromised, so have your pins. A better way would be to put a public key in DNS and protect the DNS entry via DNSSEC.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post

but this is a built-in design-flaw that activates at a known time and can never be properly fixed. it can only be worked around by upgrading. and with every upgrade the issue comes back, it's just that each upgrade delays the date when that issue becomes a problem.
(ok, that's a bit polemic, because it only applies to sites that don't dynamically update their pins, but you get the idea)
what i am wondering is, once the pin expires, is there any kind of warning to that effect?
if i understand the issue correctly: go to a site for the first time. load the certificate. preloaded pin ensures that certificate is authentic. connection to this site should be trustable until the pin AND the certificate itself expire.
as long as the pin is valid, certificate changes are trusted. once the pin expires, already loaded certificates are still trusted, but further certificate changes are no longer trusted. so that, even after the pin expires, the already loaded certificates are fine, and only when both are expired, then trouble starts.
it seems to me that updating a security certificate needs to become a two step process. and if i think about it, such a process makes sense:
greetings, eMBee.