Re: [Sks-devel] status pages on sks-keyservers.net

[Phil Pennock]

On 2013-03-23 at 15:54 +0100, Michael Nausch wrote:
> My keyserver
> http://sks-keyservers.net/status/info/keyserver.nausch.org is listed
> with some strange datas.

You might want to read:

  http://www.sks-keyservers.net/overview-of-pools.php

to get an idea of the pools being constructed from this data.

>  - Hostname is O.K.
>  - IPv6     is O.K. maked with color red - I'm fighting with my ISP
>                     about a dualstack-connection on my business
>                     connection. :/
>  - RProx    ???     whats that? reverseproxy? 

Yes.  Bear in mind that SKS is single-threaded non-forking.  One slow
client connection will tie up SKS so that it can't handle the next
client.  Best practice is to make SKS listen to localhost:11371 and then
use a reverse proxy in front of it.

You might want to read through:

  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

>  - Port 80  it's colord false with red, 'cause you can reach my server
>                     http://keyserver.nausch.org as you can reach it as
>                     http://keyserver.nausch.org:11371

As Christoph says, this is a vhost issue.  This works:
----------------------------8< cut here >8------------------------------
% telnet keyserver.nausch.org 80   
[...]
GET /pks/lookup?op=stats HTTP/1.0
Host: keyserver.nausch.org 
Connection: close

----------------------------8< cut here >8------------------------------

while if I supply a Host: header of "pool.sks-keyservers.net" then I get
a redirect to https, and if I retry with TLS on port 443, then I get a
404 Not Found.

>  - hkps     it's colord false with red, 'cause you can reach my server
>                     https://keyserver.nausch.org with root-certificates
>                     from http://www.cacert.org/index.php?id=3

So, that certificate is for "Subject: CN=*.nausch.org", and no
subjectAltNames are present.  When a client tries to connect to
hkps.pool.sks-keyservers.net, it is going to send the only trusted
hostname it has, "hkps.pool.sks-keyservers.net", and your certificate
will then fail validation.

There are two ways out of this:

 (1) Make DNSSEC a pre-requisite of ever being able to validate a pool
     hostname, chase DNSSEC-signed delegations, get a hostname under
     your control and use that (even if the hostname->IP resolution is
     unsigned).  It works, but means that all _clients_, not just
     servers, need to handle DNSSEC and DNSSEC validation.  That's an
     operationally hard issue to solve.

 (2) Make sure you have a certificate for the trusted hostname supplied
     by the client, in configuration.  So a certificate for
     "hkps.pool.sks-keyservers.net".

     With TLS SNI, you can have multiple different certificates on one
     IP address; we've worked with the GnuPG folks to make sure SNI gets
     sent, if the clients' libraries support SNI (OpenSSL, when cURL is
     linked against OpenSSL, is the main blocker, if the system has old
     OpenSSL libraries) and so it's just a matter of adding an extra
     certificate.

Look at: <http://www.sks-keyservers.net/overview-of-pools.php>
Read the section "hkps.pool.sks-keyservers.net".
Follow the instructions there to get a certificate from Kristian and
join us in providing clients with verifiable link-layer security to
public keyservers.  :)

PGP's self-signatures provide a level of object-level security which
means that, for PGP to work, link-layer security isn't strictly needed,
but having privacy on the wire to defeat analysis of whose keys you're
retrieving is a nice extra.

Oh, and continue to have a cert available for when the SNI says
"keyserver.nausch.org", because the gradual deployment of DNSSEC might
mean that at some point in the future, clients might chase delegations
and send the derived hostname.  If we have to come up with a solution to
the "problem" of deciding which of two trusted hostnames to support,
we'll already be wildly succeeding and that will be a nice problem to
have.

-Phil