Hi,
[@dkg: I know you read the last, but in this email there's one
question for you, and I would be sad if you missed it, so Cc'ing you
explicitly. Look for your handle below.]
sajolida wrote (07 Feb 2015 14:03:15 GMT) :
> ISO verification
> ----------------
I'm only commenting on that part for now. Sorry again for being late.
It would be *really* good to find more reviewers than me on this kind
of things: I'm not that good in this area (especially once it involves
the web), and I'm seriously lagging behind.
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.)
> - #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?
> 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 :)
> 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.)
> * 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?
> 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 ;)
> * 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.
* 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.
* 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.
> 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.]
> (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.
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.
Explicitly Cc'ing dkg who'll surely can correct me or make our rough
understanding of these things clearer, and add the details
I'm missing. dkg, this is about:
https://tails.boum.org/blueprint/bootstrapping/extension/
https://labs.riseup.net/code/issues/8931
> 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.
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.
> (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.
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.
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. 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?)
Congrats, amazing work!
To end with, note that I've just pushed a bunch of small commits to
the bootstrapping blueprints, that you might want to review to ensure
I didn't mess up.
Cheers,
--
intrigeri
