Re: [Tails-dev] ISO verification
Hi, sajolida wrote (03 Jul 2015 08:38:25 GMT) : > intrigeri: >> sajolida wrote (04 Mar 2015 17:43:01 GMT) : > You're answering here a quite old message of mine Yep, sorry about that. Your reply makes it clear that I should have re-read the blueprint and relevant threads more carefully before bothering to reply to this old email. >> 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.) > Not relevant anymore for the same reason. The goals section still reads "In case of a bad ISO image, help the user diagnose whether the download has been interrupted or the ISO has been corrupted", so I don't understand why my side comment isn't relevant anymore: how can we make the difference between an interrupted download, and a malicious ISO that's smaller than the genuine one? In other words: * if the ISO is too big, then by definition it's been corrupted (potentially maliciously); * if the ISO has the right size but not the correct checksum, then by definition it's been corrupted (potentially maliciously); * if the ISO is too small, then it's highly probable that the download was simply interrupted, but we can't guarantee that to the user. I've no idea what to do with this, and I totally trust you to take it into account when helping the user make a sensible decision based on this fact, in case the current wireframes don't (sorry, no time to check the details right now). >>> Are you saying that any other website that's been loaded in the >>> current session could alter the result of this verification? >>> That sounds very bad... >> >> That is what I would assume until some experts in this field tell me >> that browsers are safe about this. I guess this has been done >> elsewhere in this thread (still not finished reading it), otherwise >> you would have switched strategies since then. > Yes, that's > https://mailman.boum.org/pipermail/tails-dev/2015-April/008648.html I think. In that thread, the only answers that are potentially relevant to the question at hand are: * a message by Giorgio, who addresses mostly off-topic concerns someone else posted, but doesn't answer your questions; * a message by Kathleen, who wrote "absent a bug in Firefox or Tor Browser, other web pages should not be able to interfere"... after stating that "Mark and I do not have a lot of expertise in threat modeling" JFTR, assuming that you're basing your assessment on that second reply, I personally find it half-convincing, but giving the timing of my feedback here, I will cross fingers instead of insisting (I already feel half pissed off and half guilty wrt. how pushy I've been on this topic, so it's time for me to stop). Thanks for your work on this! Cheers, -- 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.
Re: [Tails-dev] ISO verification
On 07/07/2015 18:06, intrigeri wrote: Are you saying that any other website that's been loaded in the current session could alter the result of this verification? That sounds very bad... >>> That is what I would assume until some experts in this field tell me >>> that browsers are safe about this. I guess this has been done >>> elsewhere in this thread (still not finished reading it), otherwise >>> you would have switched strategies since then. >> Yes, that's >> https://mailman.boum.org/pipermail/tails-dev/2015-April/008648.html I think. > In that thread, the only answers that are potentially relevant to the > question at hand are: > > * a message by Giorgio, who addresses mostly off-topic concerns >someone else posted, but doesn't answer your questions; > * a message by Kathleen, who wrote "absent a bug in Firefox or Tor >Browser, other web pages should not be able to interfere"... after >stating that "Mark and I do not have a lot of expertise in threat >modeling" > > JFTR, assuming that you're basing your assessment on that second > reply, I personally find it half-convincing, but giving the timing of > my feedback here, I will cross fingers instead of insisting (I already > feel half pissed off and half guilty wrt. how pushy I've been on this > topic, so it's time for me to stop). > I'm sorry: I must have forgot to address this, or just deemed Kathleen's (correct) answer could suffice, underestimating the uncertainty effect of her "should" and "not a lot of expertise" clauses. So, just to be clear, *web pages cannot interfere in any way* with the result of the verification performed by the browser add-on, except if there are bugs in the add-on itself (very unlikely, since its code is gonna be relatively simple and high-level) or in the hosting browser (less unlikely, as we know that sh*t happens) . However such a bug would need to be of the "remote code execution vulnerability" kind, which represents a much more immediate and worrisome threat than "ability to tamper with an ISO which might or might not be installed later". This said as an expert of browser technology and web security :) -- G ___ 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.
Re: [Tails-dev] ISO verification
Hi, Giorgio Maone wrote (07 Jul 2015 23:24:07 GMT) : > So, just to be clear, *web pages cannot interfere in any way* with the > result of the verification performed by the browser add-on, except if > there are bugs in the add-on itself (very unlikely, since its code is > gonna be relatively simple and high-level) or in the hosting browser > (less unlikely, as we know that sh*t happens) . Thanks a lot for this clarification. Good to know! For completeness' sake, let me ask another one: Can a web page (and scripts it may be running) loaded in a given browser tab interfere in any way with the content of another tab? (Here, I'm defining "content" as "whatever the user sees". E.g. detecting that the verification process is ongoing, and displaying a "Verification successful" overlay or dialog box counts as interfering in this context: most users won't know that such an overlay or dialog box has a different origin and shall not be trusted.) > This said as an expert of browser technology and web security :) Yay :) Cheers, -- 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.
Re: [Tails-dev] ISO verification
> Can a web page (and scripts it may be running) loaded in a given > browser tab interfere in any way with the content of another tab? Only if it's same origin with that tab, or the content of the other tab opts-in for some form of cross-domain communication, or it's been opened with window.open() by a script in this tab or viceversa (in the latter cases it has an handle to the window of the other tab, either as the return value of window.open() or as the window.opener property, but it cannot actually touch the content unless it's same domain). Please notice that the Tor Browser provides even stronger guarantees of inter-tab insulation, but I'd dare say even those provided by vanilla Firefox are enough for our case. Of course, any tab can open an alert box saying "Verification Successful", but it cannot overlay a different tab and, most important, cannot detect any hint that the verification is happening, since it happens in the extension, rather than in the content page (ideally, as soon as e10s is ready, it would even happen in a separate process). At any rate, since the extension would be "allmighty", we can implement any UI-level strategy (e.g. going full screen or topmost on the windows stack) to ensure nothing else can tamper with user's perception. -- G On 08/07/2015 02:16, intrigeri wrote: > Hi, > > Giorgio Maone wrote (07 Jul 2015 23:24:07 GMT) : >> So, just to be clear, *web pages cannot interfere in any way* with the >> result of the verification performed by the browser add-on, except if >> there are bugs in the add-on itself (very unlikely, since its code is >> gonna be relatively simple and high-level) or in the hosting browser >> (less unlikely, as we know that sh*t happens) . > Thanks a lot for this clarification. Good to know! > > For completeness' sake, let me ask another one: > > Can a web page (and scripts it may be running) loaded in a given > browser tab interfere in any way with the content of another tab? > > (Here, I'm defining "content" as "whatever the user sees". E.g. > detecting that the verification process is ongoing, and displaying > a "Verification successful" overlay or dialog box counts as > interfering in this context: most users won't know that such an > overlay or dialog box has a different origin and shall not > be trusted.) > >> This said as an expert of browser technology and web security :) > Yay :) > > Cheers, -- Giorgio Maone https://maone.net ___ 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.
Re: [Tails-dev] ISO verification
intrigeri: > Hi, > > sajolida wrote (03 Jul 2015 08:38:25 GMT) : >> intrigeri: >>> sajolida wrote (04 Mar 2015 17:43:01 GMT) : >> You're answering here a quite old message of mine > > Yep, sorry about that. Your reply makes it clear that I should have > re-read the blueprint and relevant threads more carefully before > bothering to reply to this old email. That's ok :) You're bringing in important points anyway. >>> 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.) > >> Not relevant anymore for the same reason. > > The goals section still reads "In case of a bad ISO image, help the > user diagnose whether the download has been interrupted or the ISO has > been corrupted", so I don't understand why my side comment isn't > relevant anymore: how can we make the difference between an > interrupted download, and a malicious ISO that's smaller than the > genuine one? In other words: > > * if the ISO is too big, then by definition it's been corrupted >(potentially maliciously); > * if the ISO has the right size but not the correct checksum, then by >definition it's been corrupted (potentially maliciously); > * if the ISO is too small, then it's highly probable that the >download was simply interrupted, but we can't guarantee that to the >user. I've no idea what to do with this, and I totally trust you to >take it into account when helping the user make a sensible decision >based on this fact, in case the current wireframes don't (sorry, no >time to check the details right now). I updated the blueprint with 0d3780e. If you look at the latest wireframe, the idea now is to force people to download the ISO image through the extension (or BitT, so the extension should enforce finishing the download before starting the verification. See https://labs.riseup.net/code/attachments/download/764/extension-20150505.fodg. But the important point that you are raising here is that we didn't clarify what happens from a user point of view if the download gets interrupted (lost connection). I created #9717 to tackle this. Are you saying that any other website that's been loaded in the current session could alter the result of this verification? That sounds very bad... >>> >>> That is what I would assume until some experts in this field tell me >>> that browsers are safe about this. I guess this has been done >>> elsewhere in this thread (still not finished reading it), otherwise >>> you would have switched strategies since then. > >> Yes, that's >> https://mailman.boum.org/pipermail/tails-dev/2015-April/008648.html I think. > > In that thread, the only answers that are potentially relevant to the > question at hand are: > > * a message by Giorgio, who addresses mostly off-topic concerns >someone else posted, but doesn't answer your questions; > * a message by Kathleen, who wrote "absent a bug in Firefox or Tor >Browser, other web pages should not be able to interfere"... after >stating that "Mark and I do not have a lot of expertise in threat >modeling" > > JFTR, assuming that you're basing your assessment on that second > reply, I personally find it half-convincing, but giving the timing of > my feedback here, I will cross fingers instead of insisting (I already > feel half pissed off and half guilty wrt. how pushy I've been on this > topic, so it's time for me to stop). Sorry for being unclear, but my link was mainly to tell you that this discussion was happening in another thread (though it was not really finished there). -- sajolida ___ 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.
Re: [Tails-dev] ISO verification
Hi, Giorgio Maone wrote (09 Jul 2015 07:22:52 GMT) : >> Can a web page (and scripts it may be running) loaded in a given >> browser tab interfere in any way with the content of another tab? > Only if it's same origin with that tab, or [...] Thanks a lot for these explanations! This addresses my remaining concerns on this topic :) I guess sajolida will want to capture this reasoning on the blueprint. Cheers, -- 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.
Re: [Tails-dev] ISO verification
intrigeri: > Giorgio Maone wrote (09 Jul 2015 07:22:52 GMT) : >>> Can a web page (and scripts it may be running) loaded in a given >>> browser tab interfere in any way with the content of another tab? >> Only if it's same origin with that tab, or [...] > > Thanks a lot for these explanations! This addresses my remaining > concerns on this topic :) > > I guess sajolida will want to capture this reasoning on the blueprint. I added this in our blueprint with commit 506ef9c, I'll push it soon. I also guess that we cannot protect from another malicious extension installed in the same browser. That's now attack [I] for which I wrote commit 7ae105b: We are not considering an attacker who can: - [I] Provide a malicious extension in the same browser as this would have similar effects than attack [F]. Correct me if I'm wrong. ___ 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.
Re: [Tails-dev] ISO verification
sajolida wrote (31 Jul 2015 14:14:28 GMT) : > intrigeri: >> Giorgio Maone wrote (09 Jul 2015 07:22:52 GMT) : Can a web page (and scripts it may be running) loaded in a given browser tab interfere in any way with the content of another tab? >>> Only if it's same origin with that tab, or [...] >> >> Thanks a lot for these explanations! This addresses my remaining >> concerns on this topic :) >> >> I guess sajolida will want to capture this reasoning on the blueprint. > I added this in our blueprint with commit 506ef9c, I'll push it soon. > I also guess that we cannot protect from another malicious extension > installed in the same browser. That's now attack [I] for which I wrote > commit 7ae105b: > We are not considering an attacker who can: > - [I] Provide a malicious extension in the same browser as this > would have similar effects than attack [F]. > Correct me if I'm wrong. Thanks! Added some minor fixes on top (673921f, 05e5c80, 5ee08ac). Cheers, -- 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.
Re: [Tails-dev] ISO verification
sajolida: > 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. Following up on that old issues. Today I replaced the last mirrors that still had ETag enabled in our pool. It's now 100% ETag free :) ___ 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.
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
Hi, [@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.] sajolida wrote (07 Feb 2015 14:03:15 GMT) : > ISO verification > I'm only commenting on that part for now. Sorry again for being late. It would be *really* good to find more reviewers than me on this kind of things: I'm not that good in this area (especially once it involves the web), and I'm seriously lagging behind. I have a suggestion regarding the Seahorse Nautilus doc: * 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. * ... 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. Of course, all this complicates the OpenPGP verification process to a point when it's definitely not worth pushing to most users, so (sadly) I still agree with your conclusions. What do you think? Shall I create tickets about this? (Possibly research tickets, so that we don't have to reach a conclusion in *this* thread.) > - #8849: Technical specifications for ISO verification extension > (me, Giorgio, and probably intrigeri). More on that in a bit. Now switching to this, since I think my deadline for reviewing this was... yesterday. I'll assume that https://tails.boum.org/blueprint/bootstrapping/extension/ still captures the current state of your thinking. The Goals section doesn't address interrupted / paused / retried downloads. Is dealing with that a goal or a non-goal? > 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 :) > When the user clicks on the HTTP download button from the download > page, we propose to install the extension. 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. Perhaps the "Goals" section should have a "gracefully downgrade if JavaScript is not allowed" item? (IIRC we've discussed it and agreed on that already, but I would feel more comfortable if this was explicitly set as a goal.) > * 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 ;) > * Download the ISO again (if INCOMPLETE). > * Proposes troubleshooting strategies (if CORRUPTED). I'm curious what these troubleshooting strategies could be, and whether it makes sense to differentiate these two cases. * If the mirror serves a corrupted ISO: retrying the download should work most of the time (once we have the new mirror dispatcher thingie), just like for an incomplete download. * 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. > 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.] > (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
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
Hi, On 03/03/2015 21:01, intrigeri wrote: >> - #8849: Technical specifications for ISO verification extension >> (me, Giorgio, and probably intrigeri). More on that in a bit. > Now switching to this, since I think my deadline for reviewing this > was... yesterday. I'll assume that > https://tails.boum.org/blueprint/bootstrapping/extension/ still > captures the current state of your thinking. > > The Goals section doesn't address interrupted / paused / retried > downloads. Is dealing with that a goal or a non-goal? Considering the size of the ISO and the download speeds many Tor users may experience I'd consider it a goal (and a feasible one, too). > >> 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 :) 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? >> When the user clicks on the HTTP download button from the download >> page, we propose to install the extension. > I guess this means that JavaScript will be needed on our download > page, so that we can detect if the extension is already installed No, it doesn't. If the extension is installed it can modify the download page on the fly by hiding the bits about installing the extension itself, or redirect to a different page, with no need for site JavaScript being enabled or any detection activity being operated by the page at all. The page should just statically default to "Please install the extension", but the extension would change this default appearance if already installed. >> we could [...] Not rely on the website to perform the ISO >> verification (use the add-ons menu for example). But the UX will >> suffer from this... I'm not sure it would. Could you please elaborate? If necessary, we could even statically package our web-pages inside the add-on and present them to the user as they were from the web-site (or as a native interface, it's up to you to decide). My point is, we could hard-code all the UI inside the add-on and move the a big chunk of the website security burden to addons.mozilla.org, which is probably in a fairly better position to defend itself effectively (see below). Consider also that in a near future Firefox add-ons will all be signed by Mozilla after editorial screening (which would be quite quick in case of updates) and users won't be able to install unsigned extensions anymore: https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/ > I understand that your current threat model doesn't include MitM with > valid certificates provided by a rogue CA, which anyway makes the CA > pinning kind of a bonus feature in this context. So I'll stick to the > technical aspect to start with: > > Can an extension really do X.509 CA pinning for TLS? > (Did Giorgio comment on this one yet?) It's not trivial, but feasible. On the other hand, Mozilla's efforts to protect addons.mozilla.org (whose is pinned by default in the browser, see the HPKP blog post linked above) may be regarded as an argument in favor of moving as much as possible of the (little) user interaction needed for the download+verification process into the add-on, rather than keeping it on the web page. Last but not least, the "native" look and feel which the extension could provide might increase the perceived trustworthiness of the download process, if compared with browsing a (possibly MITMed) website. -- Giorgio Maone https://maone.net ___ 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.
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 upstre
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
intrigeri: > I have a suggestion regarding the Seahorse Nautilus doc: > > * 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. > > * ... 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. > > Of course, all this complicates the OpenPGP verification process to > a point when it's definitely not worth pushing to most users, so > (sadly) I still agree with your conclusions. > > What do you think? Shall I create tickets about this? (Possibly > research tickets, so that we don't have to reach a conclusion in > *this* thread.) Right, those could be worthy additions to the OpenPGP documentation for Linux users (and until the Installer supersedes this). But for me this is clearly outside of the scope of the assistant, so probably not handled in 2015 (at least by me). I have several other minor comments on your proposals but I won't post them here not to deviate too much from my main goal with this thread: the technical specifications for the extension. But feel free to create tickets for that. We might revamp the OpenPGP documentation at some point once the whole process is on a more sane basis for people who won't use OpenPGP (most of them). >> - #8849: Technical specifications for ISO verification extension >> (me, Giorgio, and probably intrigeri). More on that in a bit. > > The Goals section doesn't address interrupted / paused / retried > downloads. Is dealing with that a goal or a non-goal? Of course this is something we considered. As of now, we are considering keeping the download outside of the extension. For two reasons: - We consider that people know how to download a file with their browser. That should be ok. And that they also know where to find it on their file system once downloaded. That's more tricky, but they will anyway need to find it to be able to install or burn it and we can't help them here. - We want to propose the same workflow for people using BitTorrent (that's related to the next point). 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? >> 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... 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". 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. >> When the user clicks on the HTTP download button from the download >> page, we propose to install the extension. > > 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. Perhaps the "Goals" section > should have a "gracefully downgrade if JavaScript is not allowed" > item? (IIRC we've discussed it and agreed on that already, but I would > feel more comfortable if this was explicitly set as a goal.) Both Giorgio and dkg confirmed our initial hypothesis on that: even if the page has no JavaScript, the extension can do stuff on it to modify its appearances. And that could be as hiding one and displaying another one. >> * 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? Yes: - We want the people who got their download interrupted to understand what happen and not freak out. - We're not sure how to advertise corruption in case it happens but it might be slightly more worrying to see. >> 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 o
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
Giorgio Maone: >> The Goals section doesn't address interrupted / paused / retried >> downloads. Is dealing with that a goal or a non-goal? Thanks for joining this thread Giorgio! > Considering the size of the ISO and the download speeds many Tor users > may experience I'd consider it a goal (and a feasible one, too). I tried to interrupt a download of the ISO with Tor Browser and, indeed, it's not possible to continue it. 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? 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. >>> 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 :) > > 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. Another question I had is whether the extension would be allowed to rename it? In case we decide to use some trick in the filename (that's not decided yet, see #7494). >>> When the user clicks on the HTTP download button from the download >>> page, we propose to install the extension. >> >> I guess this means that JavaScript will be needed on our download >> page, so that we can detect if the extension is already installed > > No, it doesn't. > If the extension is installed it can modify the download page on the fly > by hiding the bits about installing the extension itself, or redirect to > a different page, with no need for site JavaScript being enabled or any > detection activity being operated by the page at all. > The page should just statically default to "Please install the > extension", but the extension would change this default appearance if > already installed. Yes, that's what I thought. Can you also confirm whether the extension could change *any* page on the website for example? Even if it has not been installed from this page (for example if it's shipped with the browser or installed through APT). And also, would all this be possible even in Tor Browser with JavaScript completely disabled for example? >>> we could [...] Not rely on the website to perform the ISO >>> verification (use the add-ons menu for example). But the UX will >>> suffer from this... > > I'm not sure it would. Could you please elaborate? If necessary, we > could even statically package our web-pages inside the add-on and > present them to the user as they were from the web-site (or as a native > interface, it's up to you to decide). > My point is, we could hard-code all the UI inside the add-on and move > the a big chunk of the website security burden to addons.mozilla.org, > which is probably in a fairly better position to defend itself > effectively (see below). Let's keep in mind that there are two discussions in parallel here. One about UX and one about security. And maybe I have to make it clear to you that we will integrate the extension in a bigger project, that we call "web assistant" and that will be targeted at first time users and that will lead them through the whole process from landing on our website until having a Tails ready to boot. 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. 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
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
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. >>> * I
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
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?).
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.
> 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.
>
> Another question I had is whether the extension would be allowed to
> rename it? In case we decide to use some trick in the filename (that's
> not decided yet, see #7494).
Of course it would, see above.
> Can you also confirm whether the extension could change *any* page on
> the website for example? Even if it has not been installed from this
> page (for example if it's shipped with the browser or installed
> through APT). And also, would all this be possible even in Tor Browser
> with JavaScript completely disabled for example?
Yes it would, see above.
we could [...] Not rely on the website to perform the ISO
verification (use the add-ons menu for example). But the UX will
suffer from this...
>> I'm not sure it would. Could you please elaborate? If necessary, we
>> could even statically package our web-pages inside the add-on and
>> present them to the user as they were from the web-site (or as a native
>> interface, it's up to you to decide).
>> My point is, we could hard-code all the UI inside the add-on and move
>> the a big chunk of the website security burden to addons.mozilla.org,
>> which is probably in a fairly better position to defend itself
>> effectively (see below).
> Let's keep in mind that there are two discussions in parallel here. One
> about UX and one about security. And maybe I have to make it clear to
> you that we will integrate the extension in a bigger project, that we
> call "web assistant" and that will be targeted at first time users and
> that will lead them through the whole process from landing on our
> website until having a Tails ready to boot.
>
> So, from a security point of view, I think that pushing more conte
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 instruction
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
I did a bunch of commits on the extension blueprint (7f21644..d61d155) and consider this security discussion pretty much closed. I still need to: #8855: Design data source for ISO verification extension #9028: Check whether Tor Browser disables automatic updates #9043: Check whether BitTorrent clients do proper hash verification We also started to work on the UX design. More on that later. -- sajolida ___ 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.
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. Fi
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 unde
Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]
intrigeri: > sajolida wrote (04 Mar 2015 17:43:01 GMT) : >> intrigeri: 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. You're answering here a quite old message of mine and things have changed a bit since then. We're not considering allowing people to use the extension to download and verify anything else than a direct download of the latest release. Given that people need to trust the content of our website for the extension to work, people downloading through BitTorrent already do that as well, so the extension wouldn't add any additional verification for them. >> 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 :) Not relevant anymore for the same reason. >> 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. Not relevant anymore for the same reason. 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 :) Not relevant anymore. We discarded naming the ISO image according to its verification status. >>> * 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.) Not relevant anymore for the same reason. 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 thr
