Daniel Kahn Gillmor:
> On Thu 2017-10-26 13:52:00 +0000, sajolida wrote:
>> According to our thread modeling [1], the extension cannot protect from
>> a man-in-the-middle attack on our website -- thread (B). As a MitM or
>> exploit on our website could defeat any verification technique by
>> providing simplified instructions or by faking ISO verification.
>
> I think this conclusion from the threat modeling is overly nihilistic.
Thanks for your input!
I took some time to answer your email because it always take me lots of
energy to put back these technologies (HSTS, HPKP, preload lists, etc.)
back in my head... But every time it's a bit easier :)
> Posting simplified instructions to the website is (at least sometimes)
> detectable, as is faked ISO verification, and key pinning (when coupled
> with a thoughtful and responsible key management regime) is a robust
> defense defense against CA compromise.
I agree that having HPKP on our website would be a robust defense
against CA compromise and we want to work on that (#9026). But we're not
there yet (mostly because it looks super scary to implement given the
consequences of possible mistakes).
> I'm more generally worried about chrome's deprecation of key pinning:
>
> https://groups.google.com/a/chromium.org/forum/?_escaped_fragment_=topic/blink-dev/he9tr7p3rZ8#!topic/blink-dev/he9tr7p3rZ8
>
> :( this looks like a move toward forcing everyone into the global
> monitoring regime, which works fine for the enterprise case, but might
> not be appropriate for everyone.
Uhhh, I didn't know about that, thanks! Adding this link to #9026.
> I'd prefer to see the extension use a public key pin that covers all
> connections to the tail website, not just that one download.
I'm not sure to understand you here... The extension initiates only one
download from the website: what we call the ISO Description File (IDF):
https://tails.boum.org/install/v1/Tails/amd64/stable/latest.yml
So yes, the best would be to have public key pinning on all connections,
which would mean on our website as a whole.
But my initial post was about questioning the fact that right now, we
are pinning only the IDF (with some custom pinning mechanism in the
extension [1]) but not anywhere else on the website. Though we wished we
had HPKP on the whole website, of course.
[1]:
https://git-tails.immerda.ch/ma1/download-and-verify-extension/tree/tails-download-and-verify/lib/cert-pinner.js
> giving up on several defenses because one of them has a failure mode is
> classic security nihilism, and i hope tails can avoid that kind of (easy
> to fall into) trap.
Note that I raised this question because, right now, we don't know how
to implement the equivalent of this custom pinning mechanism in Web
Extensions for new version. So we're not really "giving up" on something
because right now we don't have any pining in the Web Extension version.
My question is more about understanding better the real benefits of
doing the (potentially complicated) additional work of writing a new
custom pinning mechanism for the new extension given that we won't have
the same native API anymore.
For the other crypto operation of the extension (SHA-256) we're now
embedding a JavaScript crypto library since we don't have access to the
native Firefox API anymore. I'd be quite afraid of what it would look
like to do something similar to do certificate pinning...
But I really don't know much myself about what's possible and what's not
from withing a Web Extension, so I'm merely trying to make sense out of
what the people coding the extension are telling me :/
