Add our website to Firefox' hardcoded Public Key Pinning ("static pins")
On top of doing HPKP (see #9026) on our own which provides TOFU, we could ask for inclusion on the preload list from Firefox. Tor is getting there in Firefox 34, why not us as well?
That would be an even stronger mitigation to MitM on our website.
#6 Updated by sajolida about 4 years ago
- Subject changed from Be in the Firefox Public Key Pinning preload list to Be in the Firefox HPKP preload list
- Status changed from Duplicate to Confirmed
I'm sorry but I think that HPKP (https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04) and HSTS (https://tools.ietf.org/html/rfc6797) are two different technologies (HPKP being newer, don't ask me why). So I'm note sure we can consider that the conditions for inclusion in the preload lists are the same.
#9 Updated by intrigeri about 4 years ago
I'm sorry but I think that HPKP (https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04) and HSTS (https://tools.ietf.org/html/rfc6797) are two different technologies (HPKP being newer, don't ask me why).
Thanks for enlightening me :) ... and sorry for the additional work I made necessary.
#11 Updated by intrigeri about 4 years ago
- Assignee set to sajolida
- QA Check set to Info Needed
I'm sorry again, but I think that being in the HPKP preload list of Firefox is blocked by ourselves deploying HPKP. Otherwise, please elaborate.
Here we go. Still being under the impression that there was some misunderstanding going on here, I've read a little bit about this topic. And... it seems that I'm not the only one who was seriously confused. Given Mozilla has two wiki pages with the exact same title ("Public Key Pinning"), that are about totally orthogonal features, hosted on two different wikis, it's not exactly surprising.
The public key pinning this ticket is about is based on a (static) "preload list". It has nothing to do with HPKP, as made clear on Mozilla's HKPK documentation, that clearly states "The Public Key Pinning described here is different from the limited preload list based key pinning introduced in Firefox 32".
The way one enters that preload list is by filing a bug in Mozilla's bugzilla (see the documentation for site operators).
So, my understanding is that:
- This ticket should be retitled "Add our website to Firefox' public key pinning preload list".
- #9026 is entirely orthogonal to this ticket, and thus should not be a blocker thereof.
- This ticket should be marked as a Research one, since sadly, merely about asking Mozilla to add our website might not be enough to get us something that brings more good than bad on the long term:
- I've no idea what is the exact process to be added to that list, via the Bugzilla ticket filing. I bet they'll be nice with us, and I'm confident this will be no problem, but it would be good to know what the exact requirements are.
- What's the plan regarding updating our pinset when needed? Who's going to take care of it, in coordination with boum.org? How long does one need to plan in advance, e.g. when exactly does one need to buy a new certificate and file the bug report to Mozilla, so that the pinning is updated before the next one expires? (We need to take into account the "downloading the new ISO from Tails" use case, by the way, otherwise users might hit a painful chicken'n'egg problem when trying to use the web assistant, but failing to connect because their outdated Tails rejects the new certificate of the website.) It would be good to first research what exact change on boum.org's side would impact the pinning, and thus need to be coordinated. E.g. the feature description is confusing, and doesn't make it clear to me whether switching X.509 certificate while keeping the same CA and public key impacts the pinning or not.
Also, it's not clear to me how important this feature is wrt. the security design of the web assistant, extension, etc. Is it merely a welcome bonus, or part of what makes it sensible to rely that much on TLS? In other words, will you do the research and make it happen because you need it, or is it more like "whenever our infra people have spare time, that would be a nice thing to have"?
To end with, to answer my previous question, maybe it would help to evaluate the cost+risk/benefit ratio of this specific feature, compared to being on the HSTS preload list (#8191), and/or to supporting HPKP. My 2 cents to get this started:
- Being on the HSTS preload list is clearly weaker (it doesn't protect against a rogue CA), but it looks like a one-shot effort (except having to renew a certificate for *.tails.b.o from time to time), that doesn't require any serious research (now) nor careful planning and coordination (every 2 years or so). Also, it's way harder to fail, with the HSTS preload list, in a way that breaks our website for lots of people, compared to how it is for public key pinning (see e.g. the cryptocat fiasco).
- HPKP is closer to the HSTS preload list in terms of efforts, maintenance cost, and coping with failure. It is a bit more risky than the HSTS preload list in face of failures, but still way more forgiving than public key pinning. It also requires more coordinated maintenance work than HSTS, but way less than public key pinning. Security-wise, for web clients that are not amnesic, it's almost as good as public key pinning, particularly when combined with being on the HSTS preload list.
To end with, I suspect that the (limited, static, Firefox-specific) public key pinning preload list feature might be fully replaced, at some point, by HKPK (which is more flexible, scalable, and on its way to become an IETF standard). I suggest asking knowledgeable people at Mozilla about it, before spending too much time evaluating this feature.
Food for thought!
#14 Updated by intrigeri about 4 years ago
The thread starting at http://www.openwall.com/lists/oss-security/2015/03/22/2 has some good analysis wrt. what security HPKP and preload lists bring. It also confirms some research you've done about bittorrent.
#15 Updated by sajolida about 4 years ago
The preload list form Chrome is based on HSTS, and available in full here:
They pin their CA but not their public key directly.
They have a dedicated site to request for inclusion:
I'm not sure we could apply according to "Serve all subdomains over
HTTPS". Sure "tails.boum.org" serves everything as HTTPS and
"dl.amnesia.boum.org" is not a subdomain of "tails.boum.org". But the
cert is issued to "boum.org", which doesn't comply with this rule.
mayfirst.org is in there so we might as well ask dkg for more details.
#16 Updated by sajolida about 4 years ago
Thanks for the link. I read through it. It doesn't bring any very
different information or analysis that what we did (though less
structured). So that's good to validate that we're not missing something
#17 Updated by intrigeri about 4 years ago
The preload list form Chrome is based on HSTS, and available in full here: [...]
I suggest using a different ticket for researching what's the closest, but different, thing (to Firefox limited public key pinning) we can have for Chrome -- otherwise, I'm afraid we may mix up very different things again.
I suggest creating a ticket for CA pinning in Chrome via the HSTS preload list, that would be blocked either by #8191 (if we want to do the simple "force verified HTTPS" first, which can be done via the HSTS Preload Submission website), or by #8192 (if we want to skip the simple "force verified HTTPS", and instead go directly for CA pinning via HSTS preload list, which requires asking special treatment).
#18 Updated by sajolida about 4 years ago
Sorry for the mess, I didn't know about those tickets. So I created #9102 (Get tails.boum.org on the Chrome HSTS preload list) as a subtask of #8191 (Get tails.boum.org on major browsers' HSTS preload list) and blocked by #8192 (Get a certificate for *.tails.boum.org from the CA cartel) because of jenkins.tails.boum.org.
#21 Updated by intrigeri almost 2 years ago
- #9026 is entirely orthogonal to this ticket, and thus should not be a blocker thereof.
This was correct strictly speaking, but in practice the pre-conditions to do #9027 are a superset of the requirements to do #9026: if we are not able to advertise pinning info via a HTTP header (that can be changed easily, although that's not enough to be fool-proof given HPKP is a TOFU mechanism and browsers are caching this info locally), then there's no way we can reasonably hardcode the same info in any major web browser. So I'll re-add the blocking relationship. I've just clarified on #9026 what's needed there, what results we could aim for, and what might be a realistic timeline.
Taking a step back, as far as the IA and DAVE are concerned (relying purely on HTTPS for ISO download verification was the initial trigger for creating this set of tickets), the best we can realistically expect from #9026 + #9027 is "trusting a few CAs, instead of all of them currently, and keep trusting that the webserver that hosts our website is never going to be owned". It would be a nice improvement, but definitely not a game changer vs. the kind of adversaries I have in mind, so frankly I doubt this couple tickets are the best place to invest our time/energy/money. The only better options I can think of, that would improve the security our downloads significantly, would be to implement signature checking in our download tools: either DAVE (this doesn't have to be as complicated as OpenPGP: I guess that Web Extensions can use simple crypto primitives via NSS), or Tails Installer, as explained in blueprint/bootstrapping/verification. Personally I'd rather focus on these stronger options, so I'll take it easy on #9026.
#23 Updated by intrigeri over 1 year ago
- Subject changed from Add our website to Firefox' public key pinning preload list to Add our website to Firefox' hardcoded Public Key Pinning ("static pins")
Let's avoid ambiguity wrt. the "preload list" terminology, that is generally used to refer to something else (HSTS preload list, #8191), and make it clearer what this ticket is about :)
#32 Updated by intrigeri about 1 month ago
- Description updated (diff)
Two years after #9027#note-21, I propose we reject this ticket. If we have time/energy to put into this sort of things, I think it would be better spent on adding signature verification to our download/verification/installation process.