|
|
Subscribe / Log in / New account

Hansen: SKS Keyserver Network Under Attack

GnuPG contributors Robert J. Hansen (rjh) and Daniel Kahn Gillmor (dkg) were victims of a certificate spamming attack over the past week.

This attack exploited a defect in the OpenPGP protocol itself in order to "poison" rjh and dkg's OpenPGP certificates. Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways. Poisoned certificates are already on the SKS keyserver network. There is no reason to believe the attacker will stop at just poisoning two certificates. Further, given the ease of the attack and the highly publicized success of the attack, it is prudent to believe other certificates will soon be poisoned.

This attack cannot be mitigated by the SKS keyserver network in any reasonable time period. It is unlikely to be mitigated by the OpenPGP Working Group in any reasonable time period. Future releases of OpenPGP software will likely have some sort of mitigation, but there is no time frame. The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network.

(Thanks to Kareem Khazem.)

to post comments

Hansen: SKS Keyserver Network Under Attack

Posted Jul 1, 2019 19:16 UTC (Mon) by davidstrauss (guest, #85867) [Link] (3 responses)

> The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network.

What prevents uploading the same malicious certificates to other keyservers? Is there any reason to believe (or know) that other keyserver networks haven't experienced similar compromise?

Hansen: SKS Keyserver Network Under Attack

Posted Jul 1, 2019 19:18 UTC (Mon) by johill (subscriber, #25196) [Link] (2 responses)

As I understand it, there's basically only *one* keyserver network, and the only alternative is keys.openpgp.org which by design doesn't allow this (https://keys.openpgp.org/about/faq#third-party-signatures)

Hansen: SKS Keyserver Network Under Attack

Posted Jul 2, 2019 9:31 UTC (Tue) by wiktor (guest, #132450) [Link] (1 responses)

Yes, for keyservers https://keys.openpgp.org is a good alternative that is resistant to this type of attack.

For a distributed way of exchanging OpenPGP keys there is also Web Key Directory [0] used for example by kernel.org developers [1]. The setup is simple if one owns their e-mail domain (as it's just putting binary OpenPGP key in one special place).

[0]: https://datatracker.ietf.org/doc/draft-koch-openpgp-webke...

[1]: https://www.kernel.org/category/signatures.html#using-the...

Hansen: SKS Keyserver Network Under Attack

Posted Jul 2, 2019 16:45 UTC (Tue) by ale2018 (guest, #128727) [Link]

Yes, of course a mail site is the entity which knows who receives mail destined to a given email address.

WKD is GnuPG’s standard system for key discovery. If only Werner focuses on a final version of that draft...

Hansen: SKS Keyserver Network Under Attack

Posted Jul 1, 2019 19:23 UTC (Mon) by NightMonkey (guest, #23051) [Link]

Thank you, LWN. Just to put a finer point on this, another quote from the original:

"At present I (speaking only for myself) do not believe the global keyserver network is salvageable. High-risk users should stop using the keyserver network immediately."

And I'm truly sorry to read of the emotional effect that this thoughtless act has had on one of the early and prolific contributors of the project. My hope is that one or two or ten of the large multinational corporations that now feed off of volunteer labor of F/OSS projects will step up to put real resources behind fixing the design, usability and implementation problems detailed in the article.

Hansen: SKS Keyserver Network Under Attack

Posted Jul 1, 2019 20:31 UTC (Mon) by dd9jn (✭ supporter ✭, #4459) [Link]

FWIW, we are tracking mitigations to the problem at https://dev.gnupg.org/T4591

Eventually we need to remove the search by user id feature which is anyway a bad idea because too many users simply trust what they get back from the keyservers. Further, the Web-of-Trust is mostly a hacker's game and I guess we can do fine without and thus we can also drop any public key-signatures and thus remove a major DoS vector.

Keyservers are still useful to distribute revocations and I hope that the volunteers running the network will eventually install new software which allows just the distribution and easy access of revocations.

Hansen: SKS Keyserver Network Under Attack

Posted Jul 1, 2019 20:35 UTC (Mon) by dkg (subscriber, #55359) [Link]

More significantly than the certificates associated with Robert and myself, multiple certificates associated with the Tor project have also been flooded.

Anyone interested in ways forward for the ecosystem should look into contributing to the projects that i've linked to in my followup post and/or reading and contributing to the abuse-resistant keystore draft i've been working on.

Hansen: SKS Keyserver Network Under Attack

Posted Jul 2, 2019 8:17 UTC (Tue) by ledow (guest, #11753) [Link] (4 responses)

I think it's actually quite terrible that it's gotten to this point without it being public knowledge that (and I quote):

"The software is unmaintained. Due to the above, there is literally no one in the keyserver community who feels qualified to do a serious overhaul on the codebase."

"The keyserver network is susceptible to a variety of attacks as a consequence of its write-only design... We have known about these vulnerabilities for well over a decade. Fixing the keyserver network is, however, problematic for the reasons listed above."

As far as I'm concerned, everyone involved that knows about this is doing everyone who uses such keyservers a major disservice by not making that public knowledge, loud and clear.

Not to mention:

"These attestations — what we call certificate signatures — can be made by anyone for any purpose. And once made, they never go away. Ever. The OpenPGP specification puts no limitation on how many signatures can be attached to a certificate. The keyserver network handles certificates with up to about 150,000 signatures. GnuPG, on the other hand … doesn't. Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a halt. It doesn't stop, per se, but it gets wedged for so long it is for all intents and purposes completely unusable."

Which has nothing to do with the keyservers or their archaic unmaintainable software, but GnuPG itself, and the design of the system.

"We've known for a decade this attack is possible. It's now here and it's devastating." "At present I (speaking only for myself) do not believe the global keyserver network is salvageable. High-risk users should stop using the keyserver network immediately."

Then we should already be using keyserver-protocol-v2 (whatever that may be, and however incompatible it has to be made), and should have started work on it ten years ago.

There's an attack on the person who perpetrated this attack, calling them a fool at the bottom. I feel there should be an entirely different target here - all the people involved in such keyserver operaton and utilisation who were aware of this kind of attack who predicated such simple things as "everyday software updates" on them without ever bothering to replace them with something better the second this was known.

Turn the damn keyservers off now, deal with the carnage created, because having a poison certificate that belongs in a major mainstream package will bring *EVERYONE'S* update process to a grinding halt and put us all at serious risk... combine that attack on the right package/person with a major vulnerability in, say, Apache or SSH and you can take down almost everyone without giving them a way to update in any sensible time.

This is far more serious than an article on LWN.net. This is "switch it off!". The only time I've ever had to yell that is when there's been an actual fire, or when I suspect malware on a network (the response to which is "switch off everything suspected to be affected immediately, survey the impact, isolate, and check before bringing it back online")

Hansen: SKS Keyserver Network Under Attack

Posted Jul 2, 2019 9:27 UTC (Tue) by wiktor (guest, #132450) [Link] (3 responses)

> having a poison certificate that belongs in a major mainstream package will bring *EVERYONE'S* update process to a grinding halt and put us all at serious risk...

Distros usually keep their keychain as a separate package and update it as a package (e.g. Debian). No keyservers involved [0]. So it won't be such a big problem unless someone manually refreshes keys in that key ring (thus poisoning the key in their keyring).

[0]: Actually I think all distros do it that way as keyservers have been really unreliable for years.

Hansen: SKS Keyserver Network Under Attack

Posted Jul 2, 2019 10:49 UTC (Tue) by ledow (guest, #11753) [Link] (1 responses)

keyserver.ubuntu.com is SKS and appears to be heavily used, looking online. Maybe only a subset, but it's in instructions for installing all kinds of stuff and in official HOWTOs for checking the ISO checksum, etc.

Hansen: SKS Keyserver Network Under Attack

Posted Jul 2, 2019 13:44 UTC (Tue) by hmh (subscriber, #3838) [Link]

As long as submissions to the keyserver are gatekeeped, the current spamming attack is not a problem. Debian also runs a keyserver for internal project use, and all updates to it are manually vetoed before being accepted into the keyserver's keyring.

These restricted keyservers at most syncronize with the SKS network only on the outgoing direction: they never import data from the other keyservers (key owners must send updates explicitly to them).

This blog post seems to have some ideas as well (maybe it is repeating points already raised. I have not gone over everything yet):
https://daniel-lange.com/archives/159-Cleaning-a-broken-G...

Hansen: SKS Keyserver Network Under Attack

Posted Jul 4, 2019 5:05 UTC (Thu) by flussence (guest, #85566) [Link]

Gentoo was a notable exception that actually polled the public keyservers until caving in to mass complaints recently, when they finally fell in line with Debian's method.

The unreliability was fairly short-lived; a few months prior, the main package tree wasn't signed at all.

What does this mean for end users?

Posted Jul 5, 2019 20:07 UTC (Fri) by N0NB (guest, #3407) [Link] (1 responses)

I know almost enough about GNU PG to be almost dangerous. I do use it in the context of signing my outgoing email with GPGME and Neo Mutt. I do have gnupg configured to use 'keyserver hkp://keys.gnupg.net' to retrieve public keys. Is this server also part of the compromised SKS network?

Another comment mentions WKS. I knew nothing about this until I followed the link and did a bit more searching. I came upon this blog entry from Werner in 2016: https://www.gnupg.org/blog/20160830-web-key-service.html

Already I think this is not an option for me as the managed hosting I use does not allow me root access, so the steps he provides are moot to me.

It appears then that WKS/WKD is not an exact replacement for the SKS server network? Without using the public key servers, what are we end users to do? Do I disable keyserver lookups entirely? Do I even understand a way to mitigate the potential problem?

What does this mean for end users?

Posted Jul 6, 2019 21:09 UTC (Sat) by dd9jn (✭ supporter ✭, #4459) [Link]

keys.gnupg.net is an alias for the affected https SKS pool. It used to be a CNAME but is for quite some time an internal alias in GnuPG.

Ask you mail provider to setup a Web Key Directory (WKD). If you have your own webspace at the same domain as you mail address you can set it up for your addresses yourself. See https://wiki.gnupg.org/WKD

WKD is used to discover keys for a given mail address. If can't get a key via a fingerprint. However, if the sender used "gpg --sender MAIL [...]" gpg will be able to pick up a key for verification from the WKD, anyway. With the forthcoming 2.2.17 this will be preferred over keyservers.


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds