so each firefox version has a fixed expiry date

Story: Bug that hit Firefox and Tor browsers was hard to spot-now we know whyTotal Replies: 2
Author Content
mbaehrlxer

Sep 27, 2016
1:10 AM EDT
that is kind of worrying. Free Software should not have a known expiry date. sure, when security issues are found you ought to upgrade. but this is not just a hard to spot bug, because that implies that it can be fixed. when a security issue is fixed, i upgrade once, and the issue is gone for good.

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.

Quoting: WARNING: your browser expires on dec 15, 2016. after that day, your TLS communication is no longer secure.


(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:

* website sends a certificate. certificate is verified with browser pin. 
* before certificate expires, website sends a new pin, that is 
  valid long enough until the new certificate is available.
* browser accepts pin because it is sent from a trusted site.
* browser validates new certificate based on the pin it received.
i think this could be simplified to:

* website sends new certificate signed with old certificate.
wouldn't that be enough? if it is established that new certificates are always signed with the old ones, pins would only be needed for the initial visit from the browser, and the whole problem would go away. wouldn't it?

greetings, eMBee.
flufferbeer

Sep 28, 2016
7:27 PM EDT
@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
dotmatrix

Sep 28, 2016
8:11 PM EDT
@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.

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!