SKS Keyserver Network Under Attack

Mirimir mirimir at
Mon Jul 1 04:08:19 CEST 2019

On 06/30/2019 07:33 AM, Robert J. Hansen wrote:
>> Your third point is actually why I suggested this. Maybe I'm just
>> twisted, but what if some dickhead goes after certs that would break
>> stuff for millions of people? One might, for example, block Linux kernel
>> maintenance and development. Maybe just before using some 0-day.
> For whatever it's worth, as soon as I heard word there were poisoned
> certificates in the strong set I spoke to a friend who's well-connected
> in the kernel community and made sure to pass on the warning and the
> mitigation.
> I am not worried about the kernel hackers being hit.  They're
> technically savvy, close-knit, and largely self-sufficient technologically.

OK, that's great news. And I get from the HN thread that repository keys
are updated via signed packages, with no calls to SKS keyservers. So I'm
no longer freaking about that level of damage.

> I'm very worried about people who lack technical skills (for many
> people, just editing a config file is beyond them), who are in loose
> contact with the GnuPG/keyserver community (people who might check in
> once a year to see if there's any major updates), who are dependent on
> others for their communications ("I don't know how this works, my IT
> department sets it up for me").
> Those people are -very- vulnerable to this.  They're going to get hit hard.

Yes, people like me. Whose Enigmail was setup to query SKS keyservers.
So somehow they must be alerted.

>> It would stop when certs can no longer be poisoned.
> Please show me how we can prevent certs from being poisoned.  This is a
> phenomenally hard problem.  You are handwaving away a huge amount of
> difficulty.
> What you are saying here is, "it would never end."

Well, given what you've said about the chances that SKS keyservers will
get fixed, it would likely never end for them. From what I've read, I
gather that spam signatures to them can't be blocked.

But using keyservers like hkps://, certs couldn't be
poisoned, right? Right now, I gather, keys can't even be signed after
uploading. So basically, it would end when we switch to them, or to
another secure alternative.

And yes, hkps:// would fall over and die if too many
users started using it. So cert poisoning will be an issue until there's
a secure alternative.

>> I don't see that as "doing the bad guys’ work for them". I see it as
>> preventing bad guys escalating from hurting a few people to doing
>> serious damage. That's not "punishing the victim".
> "Look, this one guy who just got mugged?  Clearly the street gang
> doesn't like him.  So if we just, you know, don't help him, then the
> gang won't also go after us.  We're not 'punishing the victim'.  We're
> just saying, the needs of the many outweigh the needs of the few.  I
> mean, it's too bad, what's happening to him.  And it's too bad the gang
> is making us turn our backs and walk away.
> I bet that once we're a block away we're not going to be able to hear
> him screaming.
> Come on, let's walk faster."

I apologize. I know that this has been horrible for you. And I get that
it's not at all your fault.

Nonetheless, your key on the SKS keyservers is hosed. It could happen to
anyone. And given the design, it can't be fixed.

However, it's not like your key and its authentic signatures are lost.
You have it on your machines, it's at, and you
could put the key on hkps:// or another keyserver.

So it's not you that's getting thrown under the bus. It's the SKS
keyserver network that's getting thrown under the bus.

And if someone needed signatures only available from the SKS keyservers,
there must be some way to recover them. One could import the key safely,
edit the signatures, and then put it on some secure keyserver.

More information about the Gnupg-users mailing list