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
