Hansen: SKS Keyserver Network Under Attack
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.
Posted Jul 1, 2019 19:16 UTC (Mon)
by davidstrauss (guest, #85867)
[Link] (3 responses)
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?
Posted Jul 1, 2019 19:18 UTC (Mon)
by johill (subscriber, #25196)
[Link] (2 responses)
Posted Jul 2, 2019 9:31 UTC (Tue)
by wiktor (guest, #132450)
[Link] (1 responses)
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...
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...
Posted Jul 1, 2019 19:23 UTC (Mon)
by NightMonkey (guest, #23051)
[Link]
"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.
Posted Jul 1, 2019 20:31 UTC (Mon)
by dd9jn (✭ supporter ✭, #4459)
[Link]
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.
Posted Jul 1, 2019 20:35 UTC (Mon)
by dkg (subscriber, #55359)
[Link]
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.
Posted Jul 2, 2019 8:17 UTC (Tue)
by ledow (guest, #11753)
[Link] (4 responses)
"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")
Posted Jul 2, 2019 9:27 UTC (Tue)
by wiktor (guest, #132450)
[Link] (3 responses)
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.
Posted Jul 2, 2019 10:49 UTC (Tue)
by ledow (guest, #11753)
[Link] (1 responses)
Posted Jul 2, 2019 13:44 UTC (Tue)
by hmh (subscriber, #3838)
[Link]
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):
Posted Jul 4, 2019 5:05 UTC (Thu)
by flussence (guest, #85566)
[Link]
The unreliability was fairly short-lived; a few months prior, the main package tree wasn't signed at all.
Posted Jul 5, 2019 20:07 UTC (Fri)
by N0NB (guest, #3407)
[Link] (1 responses)
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?
Posted Jul 6, 2019 21:09 UTC (Sat)
by dd9jn (✭ supporter ✭, #4459)
[Link]
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.
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
More significantly than the certificates associated with Robert and myself, multiple certificates associated with the Tor project have also been flooded.
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
Hansen: SKS Keyserver Network Under Attack
https://daniel-lange.com/archives/159-Cleaning-a-broken-G...
Hansen: SKS Keyserver Network Under Attack
What does this mean for end users?
What does this mean for end users?