Re: [Sks-devel] peering broken for keyservers using reverse-proxies?

[Phil Pennock]

On 2012-04-05 at 17:32 -0400, Daniel Kahn Gillmor wrote:
> On Wed, 4 Apr 2012 18:02:49 -0600, Ryan <address@hidden> wrote:
> > I had problems reverse proxying 11371 behind a load balancer; would
> > break other sks servers fetching keys.
> 
> Yep, this seems to be the case.
> 
> I used strace to capture such a negotiation to see what was happening,
> and this is what i see on a failed connection:
> 
> write(6, "2012-04-05 12:50:07 Requesting 2 missing keys from <ADDR_INET 
> [94.142.241.93]:11371>, starting with 5855E8BFE87C212A57828BE1667C746B\n", 
> 133) = 133

Ah, the irony: I was running 1.1.1 and yet had deployed a proxy, so
would have been unable to send keys to folks with the same setup.  It
was a mistake to treat this as a non-urgent upgrade.  Remedied.

The Peering page now includes this paragraph immediately after
describing why you might want to set up a reverse proxy:

  There is currently a downside: the latest release at time of writing
  was 1.1.2, which was also the first release which correctly provided
  an HTTP version on the POST request; reverse proxies may legitimately
  drop such malformed requests (HTTP/0.9 and POST do not mix), so peers
  running releases older than 1.1.2 will fail to send you keys.
  Fortunately there are enough 1.1.2 keyservers not using a reverse
  proxy that you will receive the keys, but it will take slightly longer
  to do so. If all the 1.1.2 keyservers use a reverse proxy, then there
  will be a partitioning of the pool with unmaintained servers unable to
  sync with current best-practices servers.

When I look over https://sks.spodhuis.org/sks-peers I see that three of
the ten nginx deployments are on sks 1.1.2 (where my freshly upgraded
server is one of those three).  There are 22 1.1.2 deployments.

So at present:
 * when talking to a server which has a reverse proxy, the odds are 7:3
   against you being able to send keys to that server
 * you have a 19/22 probability of talking successfully to a server if
   it is 1.1.2.

Given the random nature of peer selection, the odds matter quite a bit.

At present, some pools drop 1.0.10 servers because of interop issues
with gnupg (if recollection serves).  I think that there will come a
point where the public pools should drop all pre-1.1.2 servers.

-Phil

pgp2NrnZOY85Y.pgp
Description: PGP signature