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 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
>
> 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.
>
> 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.
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.
--
Giorgio Maone
https://maone.net
