sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] keys.gnupg.net anomaly


From: Phil Pennock
Subject: Re: [Sks-devel] keys.gnupg.net anomaly
Date: Fri, 29 Apr 2016 05:03:10 +0000

On 2016-04-28 at 16:22 +0200, Kiss Gabor (Bitman) wrote:
> I found requests for https://keys.gnupg.net/ in my Apache logs
> on keys.niif.hu. Of course they were unsuccessful because
> my HTTP daemon is not set up to provide this virtual site.

> Phil Pennock writes on http://sks.spodhuis.org/:
> | End-users should use a pool definition, such as keys.gnupg.net which will
> | alias into an operational pool.
> 
> So this seems to be a well known situation but I don't believe
> it would be a wise thing.

This is only required for port 11371 and is explicitly covered in
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

} HTTP Performance
} [...]
} Beware that for port 11371 traffic, you *must* be able to handle
} requests with _any_ `Host:` header, for the various pools and CNAMEs
} which exist, and you *must* accept requests with no `User-Agent:`
} header set, as at least one major OpenPGP HKP client refuses to set a
} User-Agent field when talking to keyservers.

This is handled in all of the configuration examples provided.  SKS on
its own doesn't look at Host: headers and if you put a proxy in front of
it (as you should because of the single-request-at-a-time implementation
of SKS) then ideally you'll preserve this host-agnostic behaviour on
port 11371 if you wish to be a part of the public pools.

Ideally the pool DNS maintenance checks would enforce this.  The code is
available at:
  https://git.sumptuouscapital.com/
and I'm pretty sure that Kristian takes patches.

What hostnames you handle on 80/443 is a different matter.  For myself,
I prefer to avoid serving real content on arbitrary hostnames (DNS
rebinding attacks, etc) so always have a catchall dummy default with no
content.  For the SKS IP address though, the server configuration
includes the `/pks/` handling fragment even on that vhost, so that HKP
works.  I then have a vhost configuration for known pools which also
includes the `/pks/` config fragment, but has:

        location / {
            rewrite ^ $scheme://sks.spodhuis.org$request_uri redirect;
        }

so that requests for any other resource will receive redirects; this
way, if someone browses to http://ha.pool.sks-keyservers.net/ and hits
my server, they'll get a redirect _before_ getting the HTML which
includes other page resources, so other server operators won't be hit
with arbitrary URI loads because of my site.

-Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]