Closed ygrek closed 7 years ago
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
7 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
7 years ago ygrek
commented
7 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.
ygrek
commented
7 years ago ygrek
commented
7 years ago Original comment by Micah Lee (Bitbucket: micahflee, GitHub: micahflee).
Unfortunately users already incorrectly assume a level of trust in third party operators. This is why I opened this issue: because users were confused by the status quo, and thought that they could trust what they saw in the sks web app, when they can't.
But I suppose insisting that OpenPGP remains confusing and unusable for the foreseeable future is your choice.
ygrek
commented
7 years ago Original comment by Kristian Fiskerstrand (Bitbucket: kristianf, GitHub: krifisk).
The interface is too useful for debugging , but since we agree users should not be exposed to it I've removed it from sks-keyservers.net at least, which should never have been added https://git.sumptuouscapital.com/?p=sks-keyservers-pool.git;a=commit;h=b17f1b155bf5e7109d8c40734610a606ae31129a and https://git.sumptuouscapital.com/?p=sks-keyservers-pool.git;a=commit;h=8b4db8295375b811d9cd04f5dafb8bf435e3ac5c
ygrek
commented
7 years ago Original comment by Micah Lee (Bitbucket: micahflee, GitHub: micahflee).
Oh cool, does that git repo contain the branch that you're running on sks-keyservers.net?
When I load this URL, I still see the malicious UIDs on my key: https://sks-keyservers.net/pks/lookup?search=0x403C2657CD994F73&op=index
I wonder if a solution for the sks project as a whole, instead of just for this one server, could be a warning message in the web interface? The top of each page could say something like, "You should not trust any information you see here. Use an OpenPGP program like GnuPG to view information about public keys."
ygrek
commented
7 years ago Original comment by Kristian Fiskerstrand (Bitbucket: kristianf, GitHub: krifisk).
/pks is just proxied to SKS, its not related to sks-keyservers.net, just removed any direct links to it.
The solution is education of users. If the user is dependent on a notice that the information isn't to be trusted, they are lost anyways - obviously a mallicious participant will just remove the disclaimer, its just silly.
ygrek
commented
7 years ago ygrek
commented
7 years ago Original comment by Micah Lee (Bitbucket: micahflee, GitHub: micahflee).
There's a range of what people think they can trust. Some people think they if they search for an email address on a key server and find a key, that means they found that person's key. Some people know that fake keys are everywhere, but if they're looking at a key with the right fingerprint that they can trust the UIDs and signatures they see. Some people don't trust anything they see in the web UI.
If the information displayed on sks keyserver websites can't be trusted, but you still think it should be displayed because it's helpful for debugging reasons, this should be clear in the UI (doesn't necessarily have to be a warning message -- maybe it can just not be displayed at all, with a "debug info" link that shows what's in the PGP packets).
The best way to educate users is to build the education directly into their user interfaces. Otherwise they make mistakes and are told they just don't understand how it works, when in reality the UI is basically lying to them.
ygrek
commented
7 years ago Original comment by Kristian Fiskerstrand (Bitbucket: kristianf, GitHub: krifisk).
they shouldn't be on the keyserver UI at all, they should access HKP through third party tools. It just so happens that HKP is a layer over HTTP so they can visit it in browsers, although the number of questions I get on why port 80 doesn't provide the results they expect (port 11371) is curious on its own.
The UI is doing exactly what it is supposed to be doing.
ygrek
commented
7 years ago Original comment by Micah Lee (Bitbucket: micahflee, GitHub: micahflee).
So, end users simply shouldn't use the sks software in a web browser to find keys at all. Instead they should use software like GnuPG to interact with sks?
Looking at the web interface of what is one of the most active instances of sks, this is not obvious at all. In fact, the opposite is obvious. It's very clear that you can use sks to search for keys, upload keys, etc.
Maybe all of those forms on the homepage should be replaced with a short paragraph telling people to use gpg, or some other software, to interact with sks instead? (Or the web interface could just avoid displaying provably malicious results...)
But honestly, the web interface is very useful. For example, I use split-gpg in Qubes. This means that my gpg keyring is in a VM that doesn't have a network interface, and my email client/other software that uses my keys communicates to this VM in a secure manner, without actually having access to its data. But sometimes I need to retrieve a key from a key server, which is more difficult since my gpg VM doesn't have internet access. My options are: 1) use a key server web interface to search for the key, and then copy and paste it into my gpg VM to import it, or 2) use a gpg in a different VM to retrieve the key, then copy that file into my gpg VM to import it. I frequently search for keys using the sks web interface to import them into my networkless gpg VM. Having a usable sks web interface is actually useful for me, and probably for other people too. It's just silly to insist that it not do the bare minimum to try to not display known-bad information.
But if you truly feel like the web interface shouldn't be used, then the fix really should be getting rid of all of those forms that make sks searchable. The solution to bad user interfaces isn't "user education", it's fixing the user interfaces.
ygrek
commented
6 years ago Original comment by Yegor Timoshenko (Bitbucket: yegortimoshenko, GitHub: yegortimoshenko).
I've written a repro for this issue: https://gitlab.com/yegortimoshenko/sks-tools
One can add a fake UID with any signatures (say copied from other keys), see SKS Keyserver Signing Key:
ygrek
commented
6 years ago Original comment by Yegor Timoshenko (Bitbucket: yegortimoshenko, GitHub: yegortimoshenko).
The latter technique can also be used to make keys unimportable.
Try:
$ gpg --keyserver pgp.mit.edu --recv-keys 0x4F3F50786C401DCE
gpg: packet(13) too large
gpg: read_block: read error: Invalid packet
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0See: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x4F3F50786C401DCE
Screenshot: https://screenshots.firefox.com/SAkLpyR5eFAnfAcv/pgp.mit.edu
I've opened a separate issue: #57
ygrek
commented
6 years ago Original comment by ilf (Bitbucket: ilf_, ).
I think wen can reach a compromise here. How about adding an option to /pks/lookup, something like like checksigs=yes
So lookup?search=0x403C2657CD994F73&op=index&checksigs=yes would not display packets with invalid signatures.
Next we can debate which options should be default :)
(Edit: Just saw that something like this was already proposed over in the other issue: https://bitbucket.org/skskeyserver/sks-keyserver/issues/57/anyone-can-make-any-pgp-key-unimportable#comment-46218723)
ygrek
commented
6 years ago Original comment by Wiktor (Bitbucket: wiktor_k, ).
ilf I think it's by design that SKS doesn't check sigs, checking sigs should be done at the user's end. Also checking sigs would solve this one issue but wouldn't solve similar trust issues (like adding any unowned e-mail address to one's UID) or checking if the key is legitimate in the first place.
I think a simpler solution would be just removing human readable listings (index, vindex) completely, leaving only machine readable output used by gpg and friends thus conveying the message that SKS is not really for humans to use.
ygrek
commented
6 years ago ygrek
commented
6 years ago Original comment by Wiktor (Bitbucket: wiktor_k, ).
Additionally it could discourage trolls from vandalizing some popular key's listings as it currently happens with keys from well-known people.
ygrek
commented
6 years ago Original comment by Jeroen van der ham (Bitbucket: vdham, GitHub: vdham).
I would really advocate against removing the human-readable web interface. Unfortunately we are in the situation that searching in clients is not always reliable and users check results using the web interface.
The web interface is also a way for many users to distribute their key (I know it's not 100% secure, but still, this exists).
ygrek
commented
6 years ago Original comment by Wiktor (Bitbucket: wiktor_k, ).
Another way of tackling this problem is doing basic key validation on the client side instead of the server side when a person is browsing keys.
I've been experimenting with OpenPGPjs and it can download a key from the key server and do consistency checks that'd avoid fake UIDs.
Check out these links:
Micah's key: https://metacode.biz/openpgp/key#0x403C2657CD994F73
My key: https://metacode.biz/openpgp/key#0x653909A2F0E37C106F5FAF546C8857E0D8E8F074
Random people's keys:
https://metacode.biz/openpgp/key#0x1d40fba29eb39616
https://metacode.biz/openpgp/key#0x8E82E4DC
This is just a static page, downloading keys from a keyserver, parsing and validating keys using OpenPGPjs and rendering it.
Putting something like this on SKS would require no changes on the backend part as OpenPGPjs uses regular HKP protocol.
Note that this is just a proof of concept so don't use it in production like this ;)
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):
If I import the key locally, it only shows the ones that have valid signatures:
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.