Web app displays UIDs on keys that have invalid signatures

ygrek commented 8 years ago

Original report by Micah Lee (Bitbucket: micahflee, GitHub: micahflee).

Anyone can add arbitrary user ID OpenPGP packets to any public key, and the sks web app will display them, even if they don't have valid signatures.

This has happened with my key: https://pgp.mit.edu/pks/lookup?search=0x403C2657CD994F73&op=index

The display of my key shows three user IDs which I did not create (and therefore they don't have valid signatures):

trolldwot <micah@micahflee.com>
Dontuseee <micah@freedom.press>
Hacim Lee <micah@firstlook.org>

If I import the key locally, it only shows the ones that have valid signatures:

pub   rsa4096/CD994F73 2015-08-14 [SC] [expires: 2016-08-13]
      Key fingerprint = 927F 419D 7EC8 2C2F 149C  1BD1 403C 2657 CD99 4F73
uid         [ unknown] Micah Lee <micah@micahflee.com>
uid         [ unknown] Micah Lee <micah@firstlook.org>
uid         [ unknown] Micah Lee <micah@freedom.press>
uid         [ unknown] Micah Lee <micah.lee@theintercept.com>
sub   rsa4096/5D5F1356 2015-08-14 [E] [expires: 2016-08-13]

I've had multiple people tell me that they searched for the OpenPGP fingerprint they found on my Twitter profile but it says "don't use" so they're not sure if they should trust it.

This is a user interface issue with sks.

I think that either the web app should only display uids that have valid signatures, or the web app should explicitly show that uids with invalid signatures are invalid (for example, by making them red and crossed out).

But the former is probably cleaner UI, and if people really wish to see the invalid uids they can always download them and use pgpdump, just like they must to see all sorts of other information stored in a public key block.

ygrek commented 8 years ago

Original comment by Kristian Fiskerstrand (Bitbucket: kristianf, GitHub: krifisk).

keyservers, by design, does not validate signatures, it is not the role of the keyserver to do so as that would require it to be trusted. It is a pure data store. This is not a display issue, this is a misunderstanding of basic concepts and misusing the infrastructure for a role it is not intended for.

ygrek commented 8 years ago

Original comment by Micah Lee (Bitbucket: micahflee, GitHub: micahflee).

Seriously?

I just looked up the OpenPGP message format RFC, and it indeed doesn't seem to require that User ID packets have an associated "Positive certification of a User ID and Public-Key packet" Signature packet signed by the signature key to be a valid User ID. So technically, it appears that invalid UIDs don't violate the spec.

However there are no implementations of OpenPGP (that I'm aware of) that actually generate UID packets without Signature packets -- which is why you need access to the private key to "adduid" in gnupg. And there's no situation where anyone would ever want an unsigned UID packet on their key. And while it's true that anyone can add whatever they want to keyservers, it doesn't mean that sks should display obviously malicious UIDs.

PGP already has enough usability issues. It would be absurd not to fix such a simple bug that does nothing but cause more confusion.

ygrek commented 8 years ago

Original comment by Kristian Fiskerstrand (Bitbucket: kristianf, GitHub: krifisk).

Users shouldn't be thought to trust in third party services to begin with. OpenPGP is secured by an object based security model and only a local client has any chance of validating the keys and signatures in a trusted matter. Users shouldn't visit the keyservers directly, but use the clients to access it.

ygrek commented 8 years ago

Original comment by Micah Lee (Bitbucket: micahflee, GitHub: micahflee).

By the way, I still consider this a major issue. I've since learned that it's not just malicious UIDs that get displayed in the SKS web interface as if they were valid, it's also malicious revocation certificates.

It would be pretty trivial to fake-revoke every key in the strong set and upload them to key servers. When users view these keys in the a web browser, it would appear that they're all revoked.

You might not be the kind of person that strangers who are new to OpenPGP send encrypted emails to a regular basis, but I still hear from people all the time who think my key has been hacked because of the invalid UID that says "Dontuseee".

Kristian, would you mind if I fake-revoked your key, and added some fake UIDs to it as well, to demonstrate that severity of this bug?

ygrek commented 8 years ago

Original comment by Kristian Fiskerstrand (Bitbucket: kristianf, GitHub: krifisk).

It'd be somewhat annoying, it wouldn't be compromising security. I certainly can't stop you

ygrek commented 8 years ago

Original comment by Justin Troutman (Bitbucket: justintroutman, GitHub: justintroutman).

@krifisk: Unfortunately, this faulty UX can lead to a compromise in security. One crucial observation here is that users won't always use your tool in the manner that it was intended, but paying attention to usage trends says a lot about the design of your tool.

If you provide a web interface to your tool, but that interface is integrity-weak and displays bogus, untrustworthy information, the fault is not with the user for using that interface; it's the fault of the designer to provide it without clear warning.

Of course, a GUI client, and importing via CLI, will only display verified, trustworthy information, but searching via either the web UI or the CLI will show bogus data -- not just user IDs, but revocation certificates as well. If an interface makes it possible for a user to think a key is revoked when it's not, or send encrypted e-mail to an unverified user ID, then that is bad UX; not only is that bad UX, it's bad UX that leads to a bad security decision.

These interfaces should either not exist, or exist with ample warnings. Leaving this unaddressed is precisely the kind of thinking surrounding a tool that's built for the choir -- not the congregation. I hope you'll reconsider your position on this.