intrigeri:
> I have a suggestion regarding the Seahorse Nautilus doc:
>
> * we could advise users to set up something to automatically refresh
> they GnuPG keyring (the OpenPGP best practices has several
> suggestions iirc, and not just parcimonie). This addresses the
> revocation handling problem you're mentioning in the "About the
> removal of Seahorse Nautilus" section.
>
> * ... and then, we could also advise them *not* to import our signing
> key if they've already done it in the past, which gives them "TOFU
> done right". For key rollover, this can be handled with a blog post
> and transition statement.
>
> Of course, all this complicates the OpenPGP verification process to
> a point when it's definitely not worth pushing to most users, so
> (sadly) I still agree with your conclusions.
>
> What do you think? Shall I create tickets about this? (Possibly
> research tickets, so that we don't have to reach a conclusion in
> *this* thread.)
Right, those could be worthy additions to the OpenPGP documentation for
Linux users (and until the Installer supersedes this). But for me this
is clearly outside of the scope of the assistant, so probably not
handled in 2015 (at least by me). I have several other minor comments on
your proposals but I won't post them here not to deviate too much from
my main goal with this thread: the technical specifications for the
extension.
But feel free to create tickets for that. We might revamp the OpenPGP
documentation at some point once the whole process is on a more sane
basis for people who won't use OpenPGP (most of them).
>> - #8849: Technical specifications for ISO verification extension
>> (me, Giorgio, and probably intrigeri). More on that in a bit.
>
> The Goals section doesn't address interrupted / paused / retried
> downloads. Is dealing with that a goal or a non-goal?
Of course this is something we considered. As of now, we are considering
keeping the download outside of the extension. For two reasons:
- We consider that people know how to download a file with their
browser. That should be ok. And that they also know where to find it on
their file system once downloaded. That's more tricky, but they will
anyway need to find it to be able to install or burn it and we can't
help them here.
- We want to propose the same workflow for people using BitTorrent
(that's related to the next point).
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?
>> 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...
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".
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.
>> 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, as
> you note in the open questions below. Perhaps the "Goals" section
> should have a "gracefully downgrade if JavaScript is not allowed"
> item? (IIRC we've discussed it and agreed on that already, but I would
> feel more comfortable if this was explicitly set as a goal.)
Both Giorgio and dkg confirmed our initial hypothesis on that: even if
the page has no JavaScript, the extension can do stuff on it to modify
its appearances. And that could be as hiding one <div> and displaying
another one.
>> * The extension checks the size of the download to verify that the
>> download was complete.
>> * If the download was complete, the extension verifies the
>> ISO image.
>
> (Just curious, since it's cheap:) The idea is to provide different
> feedback on failure, depending on whether the download wasn't complete
> or corrupted, right?
Yes:
- We want the people who got their download interrupted to understand
what happen and not freak out.
- We're not sure how to advertise corruption in case it happens but it
might be slightly more worrying to see.
>> 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.
dkg raised another interesting point that I'll answer from his email.
I'll make sure to follow up on this discussion at some point as this is
not as urgent to solve as the verification mechanism.
>> * Download the ISO again (if INCOMPLETE).
>> * Proposes troubleshooting strategies (if CORRUPTED).
>
> I'm curious what these troubleshooting strategies could be, and
> whether it makes sense to differentiate these two cases.
About the content of those strategies, I don't know yet. About why to
make them different, I explained that earlier already. If the download
has only been interrupted, people can understand that and we should
explain it to them calmly without them freaking out.
> * If the mirror serves a corrupted ISO: retrying the download should
> work most of the time (once we have the new mirror dispatcher
> thingie), just like for an incomplete download.
Right, the solution might be the same: download again. But the feedback
might be different.
Just to give a silly example, if you have a super hacker around, it
might be interesting to show her the corrupted ISO image but not the
interrupted one.
> * 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).
>> 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. 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?
>> (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).
> 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...
I hope Giorgio can clarify this:
- How badly would our extension be vulnerable to everything else that
happens in the browser?
- Does that make a difference if it is manipulated by the user on the
page directly or through the "Add-ons" menu and a "native" interface?
>> Since the extension is targeted at new users, a MitM or exploit on
>> our website could defeat any verification technique by providing
>> simplified instructions or by faking ISO verification.
>
> That's correct only in the context of a web-guided download. If e.g.
> we had a browser extension that could single-handedly download and
> verify Tails, then it would be very much questionable to drop this
> kind of attackers from our threat model. I guess your reply will be
> something like "that's why we decided to postpone better verification
> and do it in Tails Installer". OK, OK.
Right, but then you assume that this user has external instructions to
download and verify (like I did assume in my previous example). That's
what I meant in the section "mitigate such an attack (attack B)", and
the question behind #8931 and the previous point.
If we believe strong enough in this as a worthy mitigation to attack B
then we can build stronger verification in the extension and that would
be useful for those users. Then it might be worth keeping the CA pinning
in the checksum verification if it's cheap. That would prevent people
following external documentation from suffering a MitM on the ISO
description document.
Still, I believe that the instructions on our website will be the vast
majority of cases, so it's doesn't make much sense to build much
stronger verification in the extension for the few people who might do
everything without relying on the instructions on our website. And
indeed, we should work on pushing this to the installer for everybody.
> As you can guess, I really don't like it that (B) isn't part of the
> threat model, but it seems to make sense, modulo the bits about #8931
> that are left to be researched and discussed.
Agreed. I don't like it either :( And that's why I was trying to
convince myself for so long that building more elaborate verification
mechanisms would make sense...
>> (D) Insert malicious information in our main Git repository [...]
>
> ... makes me think that we should *really* make our review'n'merge
> practices better (e.g. I have a "slight" doubt that most of us review
> merge commits, that are the ideal place to sneak in "interesting"
> changes). But that's always putting at risk what's *in* the ISO images
> we ship, so not specific to this verification extension.
I've seen you mentioned this several times already. Now you have a
ticket: #9015. Because I looked it up online on how to do that and that
seems far from being straightforward. Then I don't mind help you putting
this on the website.
> 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. But feel free to add it. Would
it then change anything?
> Last time we discussed this together, IIRC we agreed that the ISO
> description document should be retrieved from several sources,
> compared, and somehow a sensible security decision needed to be done.
> Now I see a single fetch from our website:
>
>> Connects to https://tails.boum.org/ and verifies its certificate
>> against its expected authority.
>
> 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.
Yes, I discarded this idea when discarding attack B. Now I realize that
the CA pinning is bonus. Maybe it still makes sense in the case of
external documentation, but I wouldn't build something complex like
download correlation just for that scenario.
> 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?)
I think that we got a slight misunderstanding regarding the process
here. I asked you for a quick review in private because I was discarding
attack B and this discarded in turn the other fancy techniques that we
envisioned. So I just wanted to check with you that I was not smoking
crack on this or something. Then my plan was to polish all this and
write Giorgio and dkg more explicitly and with more precise questions.
But no harm done, the discussion is wildly started now!
