SKS Keyserver Network Under Attack

1 Like

I thought it is from my end, but it was really under attack! I had a hard time importing public keys and blaming the unreliability of PGP itself, smh.

2 Likes

Today I finally looked into this further in my setup. Some notes:

  • My setup is a monster
    • whole dotfiles, not limited to gpg.conf
  • It’s not enough to edit .gnupg/dirmngr.conf to set a keyserver, because dirmngr is a daemon and thus requires config reload, killall -HUP dirmngr seems to be enough.
  • I have uploaded my public key to:
    • two git repositories
    • many git hosts
      • GitHub refuses my updated public key. Does it ever get updated or is it likely for someone to download the key from there? If GitHub, Gitlabs and Gitea do update the key at times, do they potentially hit spammed keys and die?
    • Keybase
      • I cannot figure out how to change my key there.
        • edit2: keybase pgp update
  • I had configured my key to check for updates from pool.sks-keyservers.net :scream:
    • gpg --edit-key ... and enter keyserver
  • I forgot having sent the key to Launchpad.net, but I did send my updated key to keys.openpgp.org (new preferred keyserver), pool.sks-keyservers.net, pgp.mit.edu and keyserver.ubuntu.com, so it might auto-update? I will have to check.
    • edit: it does (or must?) autoupdate as the process is uploading the key to keyserver.ubuntu.com and then pasting the fingerprint to Launchpad

I thought something weird was going on! Something keeps asking for access to my keyring…

Any updates on this attack?

What can we do?

I don’t think there are any news, you can scroll down the gist comments to the end and there is only “this has been known to be possible for ten years”.

Quoting the gist,

Mitigations

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.

Users who are confident editing their GnuPG configuration files should follow the following process:

  1. Open gpg.conf in a text editor. Ensure there is no line starting with keyserver . If there is, remove it.
  2. Open dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org to the end of it.

and I would add here:

  1. also add keyserver hkp://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion so Tor gets used whenever it’s available. Onion address proof

  2. Run killall -HUP dirmngr so the change comes to force if dirmngr was already running.

keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence.

Oh and I guess people should upload their keys at https://keys.openpgp.org/upload and confirm the email addresses as it asks to get key uids available.

If you have PGP keys, does this mean you should only store them locally (on your machine)? I’ve needed them lately for certain things.

Private keys should be kept locally, but public keys should be somewhere where people who need to encrypt to you or verify your signatures can find them and generally that place is a keyserver.

Personally my public key is available at least on:

1 Like

If you’re using Seahorse, would your PGP key be on keys.openpgp.org? (I assumed so.) What steps should we take to keep them safe?

I haven’t used Seahorse in a long time and I don’t remember if it supports sending keys to keyservers or do you have to manually gpg [--keyserver <keyserver-here>] --send-keys <id-here>.

However keys.openpgp.org is a bit of special case and you need to

1 Like

The new GnuPG 2.2.17 ignores all key signatures of key servers by default: https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html

There are additional changes to prefer WKD (https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08) over key servers.

1 Like

It seems that we now have two threads.

Edit: and the gist continues