FYI, the only email dkg answered from this thread was when
I explicitly Cc'd him, so I bet he missed this one:
sajolida wrote (04 Mar 2015 19:44:22 GMT) :
> 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.
--
intrigeri
