[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