Tails

#1 Updated by Anonymous 2016-10-03 10:22:55

Actually on https://launchpad.net/~tails.live we have a mention of our correct signing key: http://zimmermann.mayfirst.org/pks/lookup?search=0x58ACD84F&op=vindex

But the PPA itself advertises this key: http://keyserver.ubuntu.com:11371/pks/lookup?fingerprint=on&op=index&search=0x13B4A3BC273788B05F3222CE9989116846DE989F

Maybe this key should be signed by the Tails key simply?

#3 Updated by intrigeri 2016-10-03 10:53:59

> Actually on https://launchpad.net/~tails.live we have a mention of our correct signing key: http://zimmermann.mayfirst.org/pks/lookup?search=0x58ACD84F&op=vindex

Sure. That’s not very relevant to the PPA trust path in practice though, unless someone is ready to fully trust Launchpad to only display such keys after having verified that the account holder owns them (IIRC it does, but if one wants a trust path with OpenPGP to Tails Installer’s PPA, then they can’t merely believe what that Launchpad account page says).

> But the PPA itself advertises this key: http://keyserver.ubuntu.com:11371/pks/lookup?fingerprint=on&op=index&search=0x13B4A3BC273788B05F3222CE9989116846DE989F

Yes. I guess it’s the key that automatically signs the APT repo where the Ubuntu PPA infra uploads binary packages it has built from the source packages you’ve uploaded.

> Maybe this key should be signed by the Tails key simply?

Why not: this would allow users to trust our signing key, and not merely the instructions on our website, as far as installing Tails Installer is concerned.

Of course:

• it makes sense mostly if they chose “Download and verify using OpenPGP”, which is a better advertised option nowadays;
• the user will still need to trust Ubuntu’s PPA infra (all they gain is the ability to better trust that they picked the right PPA); but they’re running Ubuntu so I guess they need to trust that infra anyway.

Still, I need more info before I can dare having an opinion on this topic. I just want to make sure it’s worth the hassle, given I’m convinced that it’ll be useful only to a very, very low number of people who want+can do Web-of-Trust verification right, and are using Ubuntu, and need Tails Installer. So: are Ubuntu users exposed to the PPA key in practice? If yes, how? Does the add-apt-repository ppa:tails-team/tails-installer command ask the user to validate the PPA’s signing key, or what? In other words, what is the user story in which it matters what key the PPA’s signing key is certified with?

#6 Updated by Anonymous 2016-10-03 19:22:04

TLDR: add-apt-repository adds the repo and adds the repository’s signing key without further questions.

And they use shortids.

https://paste.debian.net/854243/ drwhax tried it:

root@tailstestje:~# add-apt-repository ppa:tails-team/tails-installer
 tails-installer is a graphical installation tool for the Tails live operating system. Screenshot: https://screenshots.debian.net/package/tails-installer
 More info: https://launchpad.net/~tails-team/+archive/ubuntu/tails-installer
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmpv75k208m/secring.gpg' created
gpg: keyring `/tmp/tmpv75k208m/pubring.gpg' created
gpg: requesting key 46DE989F from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpv75k208m/trustdb.gpg: trustdb created
gpg: key 46DE989F: public key "Launchpad PPA for Tails Live" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

#7 Updated by Anonymous 2016-10-03 19:56:29

Normally, (quoting sajolida) “if people are following our current doc, then they get the right PPA and they’re good (i assume that Ubuntu checks the key), but if people are not following our doc, then we cannot help them anyway and they can already be screwed in 10000 different other ways. so there’s no point in making our instructions more complicated than what they already are”.

But, a user who is sent to a faulty PPA or a user who found this PPA through a search engine has no way of verifying that this is the correct and trusted PPA and no way to verify that the packages which are currently signed by me are the right ones.

So a proposal would be to at least in a footnote on the installation instructions tell people that the expected key ID is the one created by Ubuntu.
And on the PPA we can add a link to the installation instructions.

#8 Updated by exploding_paint 2016-10-03 23:19:34

intrigeri wrote:
> In other words, what is the user story in which it matters what key the PPA’s signing key is certified with?

Hi, I am the user who wrote the email quoted in the description. To give you my reasoning, I asked about this because the current situation seemed inconsistent to me: either you trust that people get the right information and files from your website, then you don’t need to walk them through the process of verifying the .iso file, or you want to give them a higher level of trust (e.g. due to possible MITM attacks), then this needs to happen for all involved pieces of software.

I have to say I am not an expert in these matters, but this is the way I understand the PGP verification. That would mean the best option is to sign the PPA’s key with the main Tails key (don’t know how much hassle that is). This would also not complicate the instructions further.

#9 Updated by anonym 2016-10-04 14:48:22

u wrote:
> […] a user who is sent to a faulty PPA or a user who found this PPA through a search engine has no way of verifying that this is the correct and trusted PPA and no way to verify that the packages which are currently signed by me are the right ones.

If the user found the PPA that way, then they won’t read our documentation about this, so…

> So a proposal would be to at least in a footnote on the installation instructions tell people that the expected key ID is the one created by Ubuntu.
> And on the PPA we can add a link to the installation instructions.

… this won’t help them, right?

#10 Updated by anonym 2016-10-04 15:08:31

exploding_paint wrote:
> Hi, I am the user who wrote the email quoted in the description. To give you my reasoning, I asked about this because the current situation seemed inconsistent to me: either you trust that people get the right information and files from your website, then you don’t need to walk them through the process of verifying the .iso file, or you want to give them a higher level of trust (e.g. due to possible MITM attacks), then this needs to happen for all involved pieces of software.

It should be noted that this is the exact situation with tails-installer when installed Debian — it’s not signed with our key, but the APT repo key (see note below). And for Windows users that go the Universal USB Installer path, they only get authentication from immerda.ch’s SSL certificate. And for DAVE (the Firefox extension) users it’s also SSL.

So we provide a few very different approaches, with varying compromises between “security” and convenience, so I’m not sure if there is much “consistency” to talk about any way. :)

A difference between Debian’s APT repo vs Ubuntu PPA:s is, of course, that any Debian user will automatically trust the Debian APT key, whereas Ubuntu users will have to establish trust to any PPA key themselves (and I guess few do). However, since PPA uses the https transport for APT, an attacker that manages to get a user to fetch another “bad” PPA key will not be able to do much more than DoS the user — the https APT transport will ensure that the correct APT info (think apt update) and .deb:s (think apt install) is downloaded, and then the verification will fail thanks to the “bad” key. To go further the attacker would need to spoof the PPA SSL certificate, and I suspect that it then can tell choose whatever key it wants for any PPA. So I don’t think there’s any security concern here, really.

#11 Updated by Anonymous 2016-11-03 20:55:25

So the difference with Debian is that PPAs are 3rd party repositories after all.

#12 Updated by Anonymous 2016-11-03 20:56:44

Quoting intrigeri “it’s not clear to me how they would use whatever solution we implement to address their concerns (so for now, I have doubts that it would actually be usable and add any security).”

I think that’s perfectly valid. If we provide a trustpath for some rare power users, how would they actually use it and how would that increase their security?

#13 Updated by Anonymous 2016-11-03 20:58:53

intrigeri: “I won’t oppose us certifying the PPA key, because we can certainly certify that this key is owned by the PPA infra, but to me it’s not clear what those power-users will infer from it (and I suspect that they’ll infer something that’s wrong, i.e. that we build these packages ourselves and sign them with that PPA key, which is not the case). So whoever cares about it, feel free to do this certification and perhaps it avoids having to discuss this further.”

#14 Updated by Anonymous 2016-11-16 11:44:49

Thinking about this again (I’m just trying to talk to myself to find out how useful all this might be):

• the Debian packages are signed by me, as the maintainer with my key
• the Ubuntu packages are also signed by me: https://launchpad.net/~tails-team/+archive/ubuntu/tails-installer/+packages with my key

• As noted by anonym & intrigeri, indeed the packages are built by Debian’s and Ubuntu’s infrastructures, using respectively the APT repo key or the PPA’s key.

Furthermore, packaging files contain checksums, which make sure that the files needed to build them are the correct ones.

We do not sign Debian’s keys with the Tails key, but lots of Tails software comes directly from Debian’s repositories and is signed with various keys of various Debian maintainers.

Signing such the PPA key might infer a wrong idea of trust: we can never trust that the built packages are the correct ones, because we don’t control the build infrastructure, nor the later transmission of those files.

On the other hand, packages in Debian’s archive have undergone some review, at least at the first upload while going through the NEW queue. Ubuntu PPA’s however are to be added by users themselves and the user has to establish trust into the PPA herself. Sure, we point her to this PPA from the documentation, but if the person was MITMed, a different PPA might serve the files.

Still unsure if signing the key is a good idea. Furthermore, the PPA key does not have an expiry date, sorta bad practice for GPG.