Tails

#1 Updated by sajolida 2015-02-21 19:39:02

Downgrade attacks would still be spotted by Tails Upgraded when starting, so that’s not so much of an issue. Still, signature files would be better downloaded through HTTPS from our website, no? Plus that would make our verification instructions more consistent.

#3 Updated by intrigeri 2015-02-23 12:13:10

> Downgrade attacks would still be spotted by Tails Upgraded when starting, so that’s not so much of an issue.

Except if the old ISO is one of those that had Tails Upgrader broken in some way.

> Still, signature files would be better downloaded through HTTPS from our website, no? Plus that would make our verification instructions more consistent.

Also, if users get a fake torrent from some crappy source (which was your initial concern if I got it right), then I don’t see why that crappy source would point them to the correct detached signature for the expected ISO on our website: instead, they can point users to an old detached signature that matches the old ISO they’re distributing. So, I don’t see how having BitTorrent users download the detached ISO signature from our website would improve security. If doing that makes verification doc better, alright, though :)

Now, if the .torrent was properly verified in the first place, then there is no real need to verify the detached ISO signature after downloading the ISO (IIRC a .torrent contains a hash of the files to be downloaded, and BitTorrent clients are supposedly verifying it — to be verified). So it’s not very clear to me what the detached ISO signature referenced in the .torrent is useful for. But I don’t have the big picture in mind, so don’t take my word for it.

#4 Updated by sajolida 2015-02-26 13:03:19

redmine@labs.riseup.net:
> Except if the old ISO is one of those that had Tails Upgrader broken
> in some way.

Of course.

>> Still, signature files would be better downloaded through HTTPS
>> from our website, no? Plus that would make our verification
>> instructions more consistent.
>
> Also, if users get a fake torrent from some crappy source (which was
> your initial concern if I got it right), then I don’t see why that
> crappy source would point them to the correct detached signature for
> the expected ISO on our website.

The idea is that, this crappy Torrent source wouldn’t point them
anywhere (or at least a genuine one wouldn’t). I think that we can take
for granted that people downloading Tails through BitTorrent know where
our website is. So newcomers would go back to the web assistant for
further instructions on how to verify the ISO and install it. And
returning users should already know that their ISO has to be verified
through our website (or otherwise there’s nothing we can do to save them).

A genuine ISO image would also be named tails-i386-x.x.x-UNVERIFIED.iso
(or something like that) to make it clear it’s not verified yet.

> Now, if the .torrent was properly verified in the first place,
> then there is no real need to verify the detached ISO signature after
> downloading the ISO (IIRC a .torrent contains a hash of the files
> to be downloaded, and BitTorrent clients are supposedly verifying it
> — to be verified). So it’s not very clear to me what the detached
> ISO signature referenced in the .torrent is useful for. But I don’t
> have the big picture in mind, so don’t take my word for it.

Thanks for the extra information, that’s what I thought as well. On the
other hand, we don’t want to be to pushy and force people to do OpenPGP
verification for downloading through BitTorrent. So we would still
provide a link to the signature of the torrent but it won’t be preeminent.

#5 Updated by kytv 2015-02-26 14:05:44

sajolida wrote:
> By shipping a signature file directly in the Torrent, aren’t people downloading it more subject to possible downgrade attacks? In case a fake Torrent seeds an old ISO and an old signature file.

If I put my 0.7.2 torrent up on ShadyTracker® as the new, shiny 1.3 release, sanity checking date of the signature would prevent this scenario.

$ gpg -v --verify tails-i386-1.3.iso.asc tails-i386-1.3.iso
gpg: armor header: Version: GnuPG v1.4.10 (GNU/Linux)
gpg: Signature made Mon Jun 13 12:57:51 2011 UTC
gpg:                using RSA key 0x1202821CBE2CD9C1
gpg: using PGP trust model
gpg: Good signature from "Tails developers (signing key) <tails@boum.org>"
gpg:                 aka "T(A)ILS developers (signing key) <amnesia@boum.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 0D24 B36A A9A2 A651 7878  7645 1202 821C BE2C D9C1
gpg: binary signature, digest algorithm SHA512

Other than documentation simplification, I don’t see how shipping the .sig with the torrent is bad for users.

(I haven’t looked at the verification docs yet so I don’t know what exactly is mentioned.)

Whenever there’s a new Tails release I (almost always) put it up on the I2P trackers after swapping out the tracker, e.g.

torrent file.............: I2P_tails-i386-1.3.torrent
directory name...........: tails-i386-1.3
infohash.................: 88e7bc1124dcfc44a42cc54c5a5635d634c605fe
directory size...........: 909.9 MiB (954,133,281 bytes) (pieces: 3640; piece size: 256 KiB)
files....................: 2
created by...............: mktorrent 1.0
creation date............: 2015-02-24 00:17:06
announce.................: http://tracker2.postman.i2p/announce.php

The official torrent is identical, other than the tracker.

torrent file.............: tails-i386-1.3.torrent
directory name...........: tails-i386-1.3
infohash.................: 88e7bc1124dcfc44a42cc54c5a5635d634c605fe
directory size...........: 909.9 MiB (954,133,281 bytes) (pieces: 3640; piece size: 256 KiB)
files....................: 2
created by...............: mktorrent 1.0
creation date............: 2015-02-24 00:17:06
announce.................: http://torrent.gresille.org/announce

People that get the release from I2P can verify the release using the included signature, which, of course, they can also get (and maybe should) from the Tails site.

Because of the verification built into to the BitTorrent protocol, I wonder how many users verify the sigs anyway. Users (who are often lazy) might be less likely to verify the sigs if they’re not included.

#6 Updated by intrigeri 2015-02-26 14:24:29

>>> Still, signature files would be better downloaded through HTTPS from our website, no? Plus that would make our verification instructions more consistent.

>> Also, if users get a fake torrent from some crappy source (which was your initial concern if I got it right), then I don’t see why that crappy source would point them to the correct detached signature for the expected ISO on our website.

> The idea is that, this crappy Torrent source wouldn’t point them anywhere (or at least a genuine one wouldn’t). I think that we can take for granted that people downloading Tails through BitTorrent know where our website is. So newcomers would go back to the web assistant for further instructions on how to verify the ISO and install it.

I’m not convinced, and will explain why. Perhaps it’s not really important anymore, given the other part of the discussion (below). If you need some security discussion training about “secure” installation/upgrade systems, read on, though :)

I think there are two main cases that can result in a fake .torrent being used to download a fake Tails ISO image:

1. Newcomers following the web assistant on our website, and somehow being fed with a fake .torrent (e.g. SSL MitM). In this case, “go[ing] back to the web assistant for further instructions on how to verify the ISO” doesn’t really work: one may assume that the same attack that fed the user with a fake .torrent in the first place, can as well be used to feed them with a matching, fake detached signature, or simply with buggy verification instructions. So, moving the detached ISO signature from the Torrent to our website doesn’t add much security in this case: it raises the bar only a tiny bit for anyone who was able to set up the first half of the attack.

2. Users who get a fake .torrent from another source than our website. I agree it’s not a very interesting scenario, given “people downloading Tails through BitTorrent know where our website is”. And if they don’t know where our website is, then they will have a hard time getting the correct signing key, except if they’re part of the 42 people on Earth that can use the web-of-trust properly. So in this case, a) shipping a detached signature in the Torrent is mostly useless; and b) the detached signature shipped on our website won’t be useful either.

=> I don’t see in which practical use case we gain much security improvements by having BitTorrent users download the detached signature from our website. However, what’s clear to me is that downloading the signature is one additional step that the web assistant users need to go through, and I thought you wanted to remove as many steps as possible. OTOH I understand your point about making verification instructions more consistent, so if consistency is more important than removing one single step for you (who have the big picture in mind), fine! Let’s just not assume we’re adding security this way. Cheers!

> Thanks for the extra information, that’s what I thought as well. On the
> other hand, we don’t want to be to pushy and force people to do OpenPGP
> verification for downloading through BitTorrent. So we would still
> provide a link to the signature of the torrent but it won’t be preeminent.

Cool. You’ll want to check the part I said needed to be verified, though, before relying on it.

#7 Updated by sajolida 2015-02-27 15:02:15

> 1. Newcomers following the web assistant on our website, and somehow
> being fed with a fake .torrent (e.g. SSL MitM).

Note that I consider this case as being “game over” in terms of ISO
verification if people don’t know how to do WoT. See
https://tails.boum.org/blueprint/bootstrapping/extension/#index4h1.

> => I don’t see in which practical use case we gain much security
> improvements by having BitTorrent users download the detached
> signature from our website. However, what’s clear to me is that
> downloading the signature is one additional step that the web
> assistant users need to go through, and I thought you wanted to
> remove as many steps as possible. OTOH I understand your point about
> making verification instructions more consistent, so if consistency
> is more important than removing one single step for you (who have the
> big picture in mind), fine! Let’s just not assume we’re adding
> security this way. Cheers!

Right, when I started this discussion I was not sure about the security
implications. But I’m happy to learn that we think that it has basically
none. So this is a pure UX discussion and we’ll retake it as such and
when we needed while working on the assistant. For me it’s too early to
decide on this.

So I’m removing this from the monthly meeting agenda.

#9 Updated by sajolida 2015-03-16 16:48:00

Since we do stats on the number of downloads of the ISO images signature file, removing it from the torrent would make those stats more precise to reflect how many people in total do OpenPGP verification of our downloads.

#12 Updated by sajolida 2015-04-08 21:30:21

I think this should be sorted out when doing the second iteration of the router.

#21 Updated by sajolida 2016-02-14 11:57:59

In cc96457 for Bug #11019, I’m actually referring to the embedded signature :)