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 [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
