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

[Phil Pennock]

On 2013-03-03 at 17:15 +0100, Werner Koch wrote:
> On Thu, 28 Feb 2013 19:43, calestyo at scientia.net said:
> > I wonder how many important stuff makes it in only one of the two
> > branches...
> 
> Well, SKS should have been bug/feature compatible to PKS ;-).  Shutting
> down the sending side is a pretty standard pattern for a TCP service.
> But well, these days the Internet virtually runs on HTTP 1.0 only.

Heh, backwards compatible to NCP perhaps too, while we're at it?  :-)

SKS itself still is compatible here.  Unfortunately, SKS is
single-threaded and sees one request through to completion, so it's
unsafe to expose directly as one bad actor can lock up the keyserver for
everyone else.

So current best practice for deployment is to put a reverse proxy in
front of SKS, with that reverse proxy handling buffering and slow
clients, letting SKS get on with the next request.  See the keyservers
marked with green in the RProx column at:

  http://www.sks-keyservers.net/status/

Unfortunately, this change in practice is recent enough that we're still
shaking out the bad interactions caused by adding another moving part to
the mix.

nginx is a popular choice of reverse proxy, and it treats the shutdown
as a connection abort by default.  Various OS/patch combinations might
make this impossible to disable.  We've figured out what should be done.
Some keyserver operators have made the change, but because triggering
the bad interaction is very timing sensitive, we can't reliably detect
setups which haven't, so can't sensibly exclude them from the keyserver
pools.

  http://www.sks-keyservers.net/overview-of-pools.php

If anyone is interested in what we currently suggest for keyserver
operators, the wiki page on Peering is the place to start:

  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

and new keyserver operators are always welcome!

Regards,
-Phil, dogsbody debugger