Daniel Kahn Gillmor:
> thanks for the explicit callout, this thread has been mostly off my
> radar, and i might not have noticed it otherwise.
Thanks for joining in! As explained to intrigeri earlier on, I planned
to send you an explicit request about that after a first validity check
by him (which he did in public and in depth). So let's go!
I feel the need to explain you more about the whole idea first. As
explained earlier as well, our plan now is to combine:
1. A "web assistant" to lead people through all the process from
landing on our website to having a Tails ready to boot
2. An "ISO verification extension", as discussed here, to do a first
validity check of the ISO image.
The documentation about OpenPGP would still exist but be presented as
"additional check" for careful users.
The question I'm trying to solve here, is "what kind of verification
shall we do in the extension?" Since the whole process is mainly
targeted at newcomers and will be done through our website and in a web
browser, my current position is to keep this very minimal. But it still
makes sense to protect them from a rogue mirror or an interrupted
download (that's quite noisy on our support channels).
Later on, I think we should push more careful verification into the
installer itself. For example, Tails Installer installed from Debian
would be in a good position to do a reasonably good OpenPGP verification.
The broad picture is better explained on this blueprint:
https://tails.boum.org/blueprint/bootstrapping/verification.html
>> * ... and then, we could also advise them *not* to import our signing
>> key if they've already done it in the past, which gives them "TOFU
>> done right". For key rollover, this can be handled with a blog post
>> and transition statement.
>
> I suspect for most new users, the validation process is complex and
> foreign enough that they don't understand which parts need to be done
> only once ever, and which parts need to be done at each download.
In the introduction to this email I'm mostly talking about newcomers
because we want to work on having full upgrades done from Tails itself
quite soon as well (#7499). Then only people starting from scratch would
go through this, so that's why I consider first time users as the target
audience here.
> I don't have a good recommendation of how to improve this situation,
> because by definition they're using some O/S that we don't know about
> and can't control.
>
> Maybe there are ways that we could leverage Microsoft or Apple's
> built-in CAs somehow to provide certified ISOs on those platforms using
> the same identity, but "certified" by MS or Apple's pre-trusted roots?
> I don't really know what kinds of mechanisms exist for that, though.
I agree with that. When we get a multiplatform installer and have more
verification logic done directly in there, then we can have it do some
basic OpenPGP and be happy with it. Since it will still be as weak as
the original OS. That's also why I want to push full upgrades directly
in Tails as well: you'd install Tails once and then, never have to trust
your OS anymore to manipulate it.
> a bit of digging turns up some pretty silly UI for Apple's code signing
> (which isn't something we can use directly anyway, but probably should
> be better-protected than expecting users to notice a lock in the
> upper-right of the taskbar:
>
> http://support.apple.com/en-us/HT202369
I get an "Access Denied" on that from Tails :) That's promising!
>>> When the user clicks on the HTTP download button from the download
>>> page, we propose to install the extension.
>
> This seems like it's just moving the goalposts from verifying the ISO to
> verifying the extension; and given that extensions themselves can be
> tampered with by other extensions, it seems like it *could* raise
> issues.
>
> Though otoh we're expecting users to install gnupg on their systems to
> verify anyway, and doing that wrong (or fetching the wrong binaries)
> could result in even worse outcomes.
Agreed.
>> I guess this means that JavaScript will be needed on our download
>> page, so that we can detect if the extension is already installed, as
>> you note in the open questions below.
>
> I agree with Giorgio that it seems like this shouldn't require
> javascript if the extension is clever enough and the placement of the
> warning/recommendation is sensible but not overwhelming.
So we all agree on that.
> Note that some browsers won't be able to install any extension we're
> likely to ship (e.g. IE or Safari), so direct download does still need
> to be supported.
Yes. As part of the "web assistant" though, we won't help people with
unsupported browsers. Firefox will be the first target, and then Chrome.
I don't think that there is a really portable way of writing extensions.
So that's another argument to keep it minimal...
>>> * The extension checks the size of the download to verify that the
>>> download was complete.
>>> * If the download was complete, the extension verifies the
>>> ISO image.
>>
>> (Just curious, since it's cheap:) The idea is to provide different
>> feedback on failure, depending on whether the download wasn't complete
>> or corrupted, right?
>>
>>> tails-i386-x.x.x-VERIFIED.iso if the verification is successfully.
>>
>> I find it a bit surprising that a verified ISO hasn't its canonical
>> name in the end, given we call it differently otherwise. But well, you
>> have read more about UX than I did. Perhaps the reasons behind this
>> design decision could be explained on the blueprint so that I, or
>> someone else, doesn't propose to change that again in a year ;)
>
> fwiw, i share intrigeri's intuitions on both points above, here. I
> wouldn't object to the name change, if it's backed up by a
> plausible-sounding argument, but my instincts suggest that changing the
> name of the file may well confuse people (how many guides out there
> mention the tails ISO without the "-VERIFIED" string? how does the name
> change help (e.g. if an attacker gets between the user and the server,
> couldn't it just ship the "-VERIFIED" name in the first place via HTTP
> 302 reidirect or something similar)
That's interesting, thank you. Our first intuition was to make it more
explicit to users that ISO images have to be verified, and whether they
did that already. But what you said made me realize that this mark only
makes sense to protect against a rogue download and a rogue would either
advertise itself as "verified" already or at least not as "unverified".
And newcomers might as well not notice that something is weird in the
filename. So having this mark might actually lead to a false sense of
security and having nothing might be better.
I'm adding this info to #7494.
>>> (B) Do a man-in-the-middle attack by providing a rogue HTTPS
>>> certificate for https://tails.boum.org/ signed by a certificate
>>> authority trusted by the browser but under the control of
>>> the attacker.
>>
>> This feels outdated (or the other way round), since the "Checksum
>> verification" section says we'll be doing CA pinning. Please clarify.
>
> if you want to do pinning, you can start doing it now. fwiw, i don't
> actually recommend CA pinning, i recommend end-entity pubkey pinning
> using HPKP. You can introduce this basically any time (once you've done
> a bit of operational planning to ensure you don't shoot yourself in the
> foot), and you can even get it included upstream in the baked-in HPKP
> lists. If you have questions about how to do this operationally and
> what the best strategy is, i'd be happy to talk further with you about
> it.
>
> For something like tails.boum.org, i recommend making two backup
> end-entity keys on an offline machine, and pinning to your active key +
> these two others.
I didn't know about HPKP until today, and that looks very interesting.
By "baked-in HPKP lists" are you saying that Firefox includes a list of
public keys in its code?
>> https://tails.boum.org/blueprint/bootstrapping/extension/
>> https://labs.riseup.net/code/issues/8931
>
> I need to think a bit more about this whole proposal. I don't know
> enough about what kind of scope an extension can have -- for example,
> can it dig around in your Downloads folder? can it find things that
> were torrented and placed elsewhere on disk?
Giorgio seems to say that you can check BitTorrent downloads with the
extension. So I guess the answer to this one is "yes".
> Do you plan to ship
> gpgv.exe (e.g. from debian's gpgv-win32 package) or do you plan to do
> the OpenPGP signature verification via something like OpenPGP.js?
I pretty much discarded doing anything more elaborated than HTTPS +
checksum verification in the extension. As explain in attack B, if
someone can control what's on the website and presented to the user,
then she can defeat any verification technique in the browser by
providing simplified instructions or by faking ISO verification.
https://tails.boum.org/blueprint/bootstrapping/extension.html#index4h1
Does that make sense?
So no, I'm not considering doing OpenPGP in there anymore. But before
that we were considering using OpenPGP.js.
> I'm assuming that you plan to ship the signing key in the extension as
> well.
>
> How do the extensions get updated, if you need to change either the
> signing key or the code/ui/etc? Can the extension itself check for its
> own updates?
We send updates to addons.mozilla.org (without any kind of cryptographic
signatures). Then we need to pass a review by the Mozilla people but
that usually goes fast for updates (a couple of days?).
Other than that I don't know how often does the extension checks for its
own updates. I'll ask Giorgio.
> I'm assuming y'all are aware of the recent change in mozilla policy that
> they're only going to allow addons that were signed by
> addons.mozilla.org:
>
> https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/
>
> Is that something that's OK for your expectations for the tails
> extension?
Yes, I think that works for us.
