Re: [Sks-devel] quality of pool.sks-keyservers.net via http / https

[Phil Pennock]

On 2013-07-09 at 17:07 +0200, Stephan Seitz wrote:
> We've noticed that the redirection of http://pool.sks-keyservers.net/ at
> different pool-members could be a big show-stopper for the average user.
> I know, that doesn't matter for most of us, but it's obviously not a big
> deal to setup a unique page.
> It's not only about the design or something, some members are
> redirecting to completely different content, which leads to any kind of
> 404's because http://pool.sks-keyservers.net/pks/... doesn't exist.

I think the problem you are encountering is a *lack* of redirection.

If a site operator serves up an HTML web-page with resource links (CSS,
images, scripting) referencing the hostname as supplied by the Host:
header, that may not work well (unless the client is using SPDY).  If
the site operator serves up the same page, referencing another hostname,
that might cause cross-domain security issues, for some content.

Which is why, ideally, the server's top-level content on unrecognised
hostnames (pools, and local aliases to the pool) will immediately
redirect the user with a 302 to that server's own site, so that the page
renders locally.  For the top-level content on the :11371 port, if that
is provided by SKS itself (which doesn't do redirects) then meta refresh
tags can work.

As Kristian notes, none of this affects usage of keyservers with PKS
clients, such as GnuPG or various graphical tools.

All of that aside, If you're requesting https: of a keyserver pool, you
have some serious issues to face to get any kind of decent security,
because the keyservers are run by unaffiliated volunteers from all over
the globe, so there's no central key as required to normally get a
certificate issued to the pool hostname (which is the one that clients
will verify).

Instead, Kristian runs a dedicated mini-CA used to let server operators
register with some local key and get a cert for the pool hostname, which
when combined with TLS SNI can let server operators issue different
certs for different hostnames and so provide for verifiable identity.
See:
  http://www.sks-keyservers.net/overview-of-pools.php
for more details on hkps.pool.sks-keyservers.net.

Finally, if you're concerned about PRISM, using the public pools might
be unwise.  How do you know that the NSA and GCHQ are not running
keyservers in the public pools, so that they can get information about
which IPs are requesting which PGP key ids or doing what uid searches?

(Beware too that a lot of PRISM appears to be based around traffic
 analysis, so when using PGP and defending against that, you'll need to
 use --hidden-recipient while distributing the messages via some
 mechanism that doesn't reveal the desired target address, so not
 email).

-Phil