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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
