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 understand how
a BitTorrent tracker could "provide a malicious ISO image".
>>> (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 agree with « a MitM or exploit on our website could defeat any
> verification technique by providing simplified instructions or by faking
> ISO verification », then we can't consider attack B. But then I
> understand that it doesn't make sense to do CA pinning. Unless people
> follow external documentation and don't rely on our website at all (more
> on that later).
OK, it seems that we were not looking at this section at the same zoom
level. That section is called "ISO verification mechanism", so I was
commenting specifically on this topic, and then if we're doing CA
pinning, the ISO verification mechanism is supposedly resistant to
(B). But wit with the big picture in mind, you're right to say that
(B) indeed cannot be addressed.
>> And below, in the same section about the (B) attacker:
>>
>>> 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...
>>
>> Keep in mind that it's not about *our* website only. It's about
>> anything that can affect the browser's environment, that is basically
>> any other website that's been loaded in the current session. You might
>> still want to *not* take this case into account in your design goals,
>> but then please make it clear, e.g. by adding another kind of attacker
>> you are not considering.
> Let's say I'm following instructions from a book which explains not to
> trust tails.boum.org, how to install the extension from AMO instead and
> use it from the "Add-ons" menu. 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.
>> Also, the list of "attackers" lacks something like:
>>
>> (G) Insert malicious content on https://tails.boum.org/ after taking
>> control of the web server, or entire system, behind it.
> Right, I didn't put it because for me it wasn't different from (C) in
> terms of what the user is experiencing.
Right, but when defining attackers we want or don't want to defend
against, what the user is experiencing doesn't matter that much :)
> But feel free to add it. Would
> it then change anything?
I see it's been added already. Great, thanks!
Cheers,
--
intrigeri
