[Sks-devel] Keyserver operators with reverse proxies: read this please

[Phil Pennock]

Folks,

We now have two separate issues affecting SKS (and GnuKS) keyservers
which have nginx or Apache in front of them, affecting interop
compatibility with various versions of GnuPG (and other clients) as
deployed.

Even as changed clients roll out, we can expect to see clients which
have issues for years to come.  We need keyservers to also work around
these issues.

I have updated
<https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering> already.


Apache
------

By default, breaks all clients which use a real libcurl, blocking their
ability to POST (--send-key) to the server.  The clients set an "Expect:
100-continue" HTTP/1.1 header and unfortunately Apache actually
implements the part of the HTTP specification (RFC2616) which says that
a HTTP/1.1 proxy should issue a "417 Expectation Failed" response if it
would pass onto an HTTP/1.0 server.

I strongly suspect that this:

    RequestHeader unset Expect early

will fix Apache configurations, but need someone using Apache to confirm
it.  You also need the mod_headers module loaded.  The version in the
wiki wraps that in an IfModule guard, but we should look at making sure
that works and then encourage people to make it a hard failure if the
directive is not available.

You can test the fix by using a GnuPG built against libcurl (*not*
curl-shim) and try to --send-key your own key to your keyserver:

  gpg2 -v --keyserver-options verbose,debug --keyserver YOURSERVER --send-key 
YOURKEY

This currently fails reproducibly, every time, for an Apache server.  If
it stops failing with the "RequestHeader unset Expect early" directive,
you know you've fixed it.  Please let us know if this works or not!
Feedback is needed.


nginx
-----

It is possible to shut down an TCP connection for reading or writing,
but not both.  This is a grey area when used with HTTP and it turns out
it causes real-world issues.

If GnuPG2 has been built *without* libcurl, then when retrieving a key
(GET, --recv-key) it will shutdown(sock, SHUT_WR) after sending the
request.  GnuPG1 used to do this too, but was fixed some time ago.

When nginx sees this happen, it treats the half-shutdown as a connection
abort and drops the request, closing immediately without an error
response even.

This results in timing-sensitive failures when talking to nginx unless
nginx is configured to avoid this.  You can most reliably check the
issue by trying a retrieval from another machine on the same network as
the keyserver, but not the machine itself.

  gpg2 -v --keyserver-options verbose,debug --recv-key YOURKEY

and check the output for:
  gpgkeys: curl version = GnuPG curl-shim

There are two parts to the fix.  First, for any server/location which
proxies PGP client requests, add:

  proxy_ignore_client_abort on;

to the configuration.

Second: if you're using the SPDY patch (at least on Kqueue systems, such
as the BSDs), then for now, please stop.  It causes the request to
_always_ be dropped, earlier than the above check.  It's an experimental
feature patch, and this is a good example of why it's still
experimental.

Thanks,
-Phil

pgpu58GgRpaUW.pgp
Description: PGP signature