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
> your filesystem.
Indeed.
>> From a UX point-of-view, I said that the "UX will suffer from this"
>> because at first sight having the verification process integrated on the
>> website seems to be less complicated than having to interact with menus
>> and a native interface. But on the other hand, I also like the idea of
>> having the user perform an explicit move to do the verification and as
>> you said a native interface might look more trustworthy.
>>
>> So now, I'm more into the native interface. But I need to check with my
>> other fellow UX people.
>
> I'm fine with whatever the UX crew deems best.
> I was just trying to lay the available options down on the table,
> especially in case anybody is not very familiar with Firefox extensions
> and their ecosystem, but I've got no strong preference of my own.
I really appreciate that as well. I'll update the blueprint in the
coming days with all the precious information that you provided us.
I'm pretty sure now that regarding the verification mechanism we should
keep it minimal and do a simple checksum verification from a file
downloaded on our website.
Then we'll work on the UX specification at the end of the month and keep
you updated.
> In another message you asked how often add-ons check for updates: it's
> once per day on a secure channel (the update pings are used also to
> generate add-ons usage stats), but I believe the Tor Browser disables
> automatic updates on purpose, even though enabling them for our
> extension only would be more a matter of policy decisions than a
> technical issue.
Well noted! I'll write this down somewhere in the blueprint as well.
--
sajolida
