Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
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
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
sajolida wrote (04 Mar 2015 17:43:01 GMT) : intrigeri: The Goals section doesn't address interrupted / paused / retried downloads. Is dealing with that a goal or a non-goal? [...] Still, our goals make it clear that we want to be able to distinguish between corrupter and interrupted downloads (4th bullet point). What would you clarify? It's been clarified already, apparently: In case of an interrupted download, help the user resume it. This requires us to have our mirrors stop sending HTTP ETag headers. See ticket #9022. :) Allow users who are downloading using BitTorrent to do the same level of verification as people downloading through their browser. IMO that could be demoted to a bonus goal, if time resources become scarce along the way. But perhaps we can postpone this discussion, and hopefully it won't be needed :) If that's a bonus, then how do those people verify their ISO image? If the answer is using OpenPGP, then I'm afraid I'll propose to stop advertising BitTorrent download in equally with HTTP download... Fair enough. Note that all this works under the condition that the extension can verify file downloaded not through it. But in his answer Giorgio seems to mean that this is no problem. Anyway that point was on our radar already, see Open questions. Great :) If we remove the download from the extension, and ask everybody to pick up the file from their file system, then supporting BitTorrent downloads comes for free. Indeed, but then we can't do certificate pinning from the extension, and have to rely on whatever certificate verification the browser does. 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 ;) This is somehow related to #7494 (I updated its description to include that proposal). My intuition is that if the unverified ISO makes it explicit, then the verified ISO have to make it explicit too. It's like traffic lights. They could theoretically be simplified into only a red light (with no light meaning go. But the green light is here to make it clear that the system is working and it's safe to go. OK, thanks: I now understand your point better. I'm not fully convinced that this analogy works that well here, though: in the case at hand, we're not trying to distinguish two roughly equivalents binary states, but what we want to distinguish is the thing and something that might, or might not, be the real thing. In this case, calling the thing with its own name (that is, tails-i386-$version.iso) *feels* clearer to me than giving it any different name (even if it's -VERIFIED). And that matches users' past experience e.g. with temporary files browsers and P2P software often create while downloading a file: I've seen some append .part, and then remove it so that the downloaded file ends up having the expected name in the end. But it looks very much like a matter of taste and intuition, so I won't insist :) * If some network attacker modifies the ISO on the fly: retry from another ISP, or using Tor, something like that could work? = I guess that's the reason why you want to handle it differently than an incomplete download, but the blueprint doesn't make it clear. See f38d56b (that's a bit minimal I admit). Thanks. (Food for thought: this seems to assume that an ISO voluntarily corrupted by an attacker will generally not be smaller than the genuine one. Not sure how good an assumption this is.) We are considering here an attacker who can: (A) Provide a malicious ISO image to the user for example by operating a rogue Tails mirror or BitTorrent tracker. I don't get the BitTorrent tracker part. I'm no BitTorrent expert, but if the .torrent is genuine, then the tracker should not be able to have seeds provide malicious data without the client noticing, right? [As said elsewhere, one should check if popular BitTorrent clients actually do check the hashes found in the Torrent file, though.] Then that could be a rogue .torrent file. OK, so I'm glad the referrence to or BitTorrent tracker was removed, since it indeed didn't make sense. But maybe you think that people who don't download their torrent file from our website are not going through the assistant anyway and won't do the verification through the extension either and are thus hopeless (unless they know OpenPGP). That might very well be the case. If so, then I understand better your idea of putting BitTorrent as bonus goal. Is that why? No, I was merely pointing out that I didn't understand how a BitTorrent tracker could provide a malicious ISO image. (B) Do a man-in-the-middle attack by providing a
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
Giorgio Maone:
On 04/03/2015 19:46, sajolida wrote:
I tried to interrupt a download of the ISO with Tor Browser and,
indeed, it's not possible to continue it.
This seems due to a misconfiguration of your mirrors setup.
Specifically, I've tried to manually resume an interrupted download from
Firefox's download manager, which should have theoretically worked
because the (initial) server (announcing itself as Server: Apache)
sent an Accept-Ranges: bytes header.
Unfortunately when I sent the second request with Range:
bytes=37053248-, the second server I was dispatched to announcing
itself as Server: lighty) actually answered with
HTTP/1.1 206 Partial Content
Content-Range: bytes 37053248-954132479/954132480
Content-Length:917079232
i.e. correctly resumed the download, but the brower refused to go on
because the first response (from Apache) carried an
Etag: 7c08c-38dee800-50fcad82a1400
header, while the second one (from Lighttpd) had
Etag: 1421032332
misrepresenting the payloads as two different entities.
Now, the easiest solution seems to me preventing Etag headers from being
sent in the ISO download HTTP responses (who's gonna *cache* a 1GB
response anyway?).
Thanks for investigating all this! I created a parent ticket to work on
this, see #9022 and subtasks.
Otherwise, you need to synchronize all the mirrors to serve the same
Etag (e.g. I hit another server, announced as nginx, with Etag:
54ebc9d0-38dee800). For instance you could use
Tails-image-{SHA256_checksum} to build an unique Etag valid for that
specific ISO version.
So I might reconsider what I just said in my answer to intrigeri :P
Still, I like the idea of having the verification experience for
people downloading through HTTP and through BitTorrent being the same.
I also like the idea of making an explicit and intentional move to
verify the ISO (instead of making it happen automatically). I
understand from your proposal Giorgio that the extension could be able
to resume an interrupted or paused download, right?
Yes it could, and I could probably work-around even the aforementioned
mirror server misconfiguration by intercepting the http responses before
they're examined by the browser forcibly filtering out the Etag headers,
if necessary, but the ideal solution would be fixing it so anyone can
use any browser or download manager to resume interrupted downloads.
I agree that we should rather fix that problem at its root.
Then I'll take good note of this and will try to take a decision
during our next UX sprint (when we should be able to finalize all the
UX side of things). For example, maybe the download process can be
done only if people choose HTTP download, and then the verification
process could still be done in the same way for everybody. But I'm
more worried about the security discussion for the moment.
[...]
Providing a menu item or an option button somewhere to browse the
filesystem and manually choose the file to be verified is simple
enough. Am I missing some other requirement for this feature which
would add complexity?
Not that I can think of. But you are answering here one of the questions
I had for you, since you are saying that the extension would be allowed
to browser or any file on the file system (for example from a BitTorrent
download) and verify that as well. That's good news.
Confirmed. Basically the extension can do anything the browser itself
can do.
Understood.
So, from a security point of view, I think that pushing more content on
AMO doesn't solve the root of the problem: if someone is in control of
tails.boum.org (through MitM or exploit) then they can fool all those
newcomers with whatever rogue verification process even earlier in the
website. Even if I agree that AMO are in a better position to defend
themselves, visitors of tails.boum.org might be tricked not to install
the extension ever.
Yes, I understand, and as a mitigation I'd advise to start deploying
HPKP on tails.boum.org ASAP, see
https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
Sure, I read more about that and understood that we should:
- First, deploy it ourselves, that's #9026.
- Then have our keys pinned in the Firefox preload list, that's #9027.
That sounds really worth it!
The only way we could mitigate such an attack (MitM or exploit on
tails.boum.org) is in the case of people following an external
documentation (for example from a book) that doesn't rely on
tails.boum.org at all. Then indeed it make sense, from a security point
of view, to do the verification in a native interface.
... or if a web search for Installing Tails or Download Tails ISO
returned https://addons.mozilla.org/addon/tails-downloader, and the
add-on description page provided very concise instructions (Press the
green button to download and verify a Tails ISO image), then after
pressing the button you automagically received a verified image in
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
On Tue 2015-03-03 21:01:55 +0100, intrigeri wrote: [@dkg: I know you read the last, but in this email there's one question for you, and I would be sad if you missed it, so Cc'ing you explicitly. Look for your handle below.] thanks for the explicit callout, this thread has been mostly off my radar, and i might not have noticed it otherwise. * we could advise users to set up something to automatically refresh they GnuPG keyring (the OpenPGP best practices has several suggestions iirc, and not just parcimonie). This addresses the revocation handling problem you're mentioning in the About the removal of Seahorse Nautilus section. This sounds like it makes a lot of sense. I wish this kind of action was more trivially accessible via gpg itself, or some other common wrapper. * ... 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. 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. 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 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. 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. 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. * 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) (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
