Feature #9027

Add our website to Firefox' hardcoded Public Key Pinning ("static pins")

Added by sajolida 2015-03-06 19:35:47 . Updated 2019-04-27 14:18:13 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
2015-03-06
Due date:
% Done:

0%

Feature Branch:
Type of work:
Communicate
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

On top of doing HPKP (see Feature #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.

See https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning

Current pins: https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h

Subtasks

Related issues

Related to Tails - Feature #8191: Get tails.boum.org on major browsers' HSTS preload list Resolved 2014-10-31
Related to Tails - Feature #9026: Deploy HPKP Rejected 2015-03-06
Related to Tails - Feature #16675: Consider using the Expect-CT header for Certificate Transparency on our website Confirmed

History

#1 Updated by sajolida 2015-03-06 19:36:00

  • Description updated

#2 Updated by sajolida 2015-03-06 19:36:44

#3 Updated by intrigeri 2015-03-06 19:51:21

  • is duplicate of Feature #8191: Get tails.boum.org on major browsers' HSTS preload list added

#4 Updated by intrigeri 2015-03-06 19:51:54

#5 Updated by intrigeri 2015-03-06 19:54:49

  • Status changed from Confirmed to Duplicate

sajolida wrote:
> Tor is getting there in Firefox 34, why not us as well?

Because this would break important parts of our infrastructure. See Feature #8192 for the details.

#6 Updated by sajolida 2015-03-10 16:16:36

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

#7 Updated by sajolida 2015-03-10 16:17:27

#8 Updated by sajolida 2015-03-10 16:18:16

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.

#9 Updated by intrigeri 2015-03-10 20:12:43

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

#10 Updated by intrigeri 2015-03-15 11:48:43

  • has duplicate deleted (Feature #8191: Get tails.boum.org on major browsers' HSTS preload list)

#11 Updated by intrigeri 2015-03-16 22:29:30

  • 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”.
  • Feature #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 (Feature #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!

#12 Updated by sajolida 2015-03-17 13:22:21

#13 Updated by sajolida 2015-03-17 13:23:17

  • Subject changed from Be in the Firefox HPKP preload list to Add our website to Firefox' public key pinning preload list

Did the Redmine work for now, will investigate the rest later.

#14 Updated by intrigeri 2015-03-23 14:55:06

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 2015-03-23 23:04:42

The preload list form Chrome is based on HSTS, and available in full here:

https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json

They pin their CA but not their public key directly.

They have a dedicated site to request for inclusion:

https://hstspreload.appspot.com/

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 2015-03-23 23:06:08

> http://www.openwall.com/lists/oss-security/2015/03/22/2

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

#17 Updated by intrigeri 2015-03-24 09:30:04

> 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 Feature #8191 (if we want to do the simple “force verified HTTPS” first, which can be done via the HSTS Preload Submission website), or by Feature #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 2015-03-24 14:59:15

Sorry for the mess, I didn’t know about those tickets. So I created Feature #9102 (Get tails.boum.org on the Chrome HSTS preload list) as a subtask of Feature #8191 (Get tails.boum.org on major browsers’ HSTS preload list) and blocked by Feature #8192 (Get a certificate for *.tails.boum.org from the CA cartel) because of jenkins.tails.boum.org.

#19 Updated by sajolida 2016-03-21 15:10:23

  • QA Check deleted (Info Needed)

#20 Updated by intrigeri 2017-05-28 12:16:31

  • related to Feature #8191: Get tails.boum.org on major browsers' HSTS preload list added

#21 Updated by intrigeri 2017-05-28 12:44:29

intrigeri wrote:
> * Feature #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 Feature #9027 are a superset of the requirements to do Feature #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 Feature #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 Feature #9026 + Feature #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 Feature #9026.

#22 Updated by sajolida 2017-11-03 13:05:54

#23 Updated by intrigeri 2017-12-15 08:09:47

  • 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, Feature #8191), and make it clearer what this ticket is about :)

#24 Updated by intrigeri 2017-12-15 08:11:18

This technique is going to be deprecated in Chrome “at a point in the future”: Feature #9026#note-9.

#25 Updated by intrigeri 2018-06-05 09:55:13

  • Target version set to Tails_3.8

(I guess it’ll be cheaper to do this at the same time as Feature #9026#note-11 than in isolation :)

#26 Updated by sajolida 2018-06-25 16:17:46

  • Target version changed from Tails_3.8 to Tails_3.9

#27 Updated by sajolida 2018-08-02 11:19:05

  • Target version changed from Tails_3.9 to Tails_3.10.1

#28 Updated by sajolida 2018-10-21 20:37:42

  • Target version changed from Tails_3.10.1 to Tails_3.11

#29 Updated by sajolida 2018-12-10 15:46:20

  • Target version changed from Tails_3.11 to Tails_3.12

#30 Updated by sajolida 2019-01-28 18:45:32

  • Target version changed from Tails_3.12 to Tails_3.13

#31 Updated by sajolida 2019-03-18 11:30:53

  • Target version changed from Tails_3.13 to Tails_3.14

#32 Updated by intrigeri 2019-04-12 07:29:08

  • Description updated

Two years after Feature #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.

#33 Updated by sajolida 2019-04-27 14:17:58

  • related to Feature #16675: Consider using the Expect-CT header for Certificate Transparency on our website added

#34 Updated by sajolida 2019-04-27 14:18:13

  • Status changed from Confirmed to Rejected
  • Assignee deleted (sajolida)
  • Target version deleted (Tails_3.14)