Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop

[David Shaw]

On Mar 2, 2013, at 2:14 AM, Phil Pennock <gnupg-devel at spodhuis.org> wrote:

> To see this, it needs to be a keyserver with an nginx proxy which has
> not yet rebuilt/reconfigured to avoid treating the write shutdown as a
> connection abort, you must have curl-shim in use, and you must be just
> the right network distance from the keyserver that you _usually_ succeed
> in connecting and getting data back, but the abort is processed while
> the connection is still returning data.
> 
> For me, that's the distance between sks.spodhuis.org and
> keys2.kfwebs.net, especially when connecting over IPv6.
> 
> It's still the nginx component in play, because this doesn't happen
> without the shutdown(sock, SHUT_WR).
> 
> Do you think it's worth GnuPG detecting that it got truncated results by
> the missing final armor line and handling that with an explicit warning
> that it only got part of the keydata and signatures might be missing?

I think this is sufficiently obscure (an old version of GPG2 that still has the shutdown() code, built with curl-shim, talking to a keyserver that is behind a nginx proxy, which has to have a particular configuration) that it is not worth putting in a special case for.  Change any of the above requirements and it no longer happens.  Especially since GPG2 will now come without the shutdown() code anyway, I don't see any benefit in special-casing this.

Note it's also not a case of just signatures missing.  It's part of the *key* that's missing.  If things were cut off in the midst of the signature block, then that implies you're missing the subkeys as well.  Worse, say things were cut off so that you got a subkey, its binding signature, but then the revocation for that subkey was cut off.

As I see it, the real problem here is that there are only two cases in the keyserver code: got a key, and didn't get a key.  "Didn't get a key" is reported to the user as "key not found" due to the old pks server which returned HTTP 200 even for key not found, so there was no reliable way to tell the difference between failure and not-found.  I vaguely recall that someone was enhancing sks so that it returned a proper 404 for key-not-found.  If that has happened, then I can can add code to GPG to have the proper three states: got a key, failed to get a complete key (where you may be left with part of a key), and key not found.  That should resolve the problem with informing the user.

A quick check of a few sks servers show that keys2.kfwebs.net does properly return a 404 for an unknown key.  pgp.mit.edu returns a 500, but this is also running an older version of sks, possibly before the 404 was added.

David