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 _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
