HKP keyservers over SSL
dshaw at jabberwocky.com
Thu Apr 2 04:42:36 CEST 2009
On Mar 31, 2009, at 5:53 PM, Phil Pennock wrote:
> On 2009-03-12 at 09:10 -0400, David Shaw wrote:
>> A few weeks ago, I added support for SSL to the HKP keyserver handler
>> (gpg(2)keys_hkp) to help test some new keyserver work that is going
>> on. (Though "Added" is a bit of a strong term - it's really just 4-5
>> lines of code to tell libcurl to accept SSL.) Anyway, Werner pointed
>> out that we may want to do something more than that. After all,
>> manipulates X.509 certificates for lunch.
>> So, let's talk about it a bit: How can we do something smart here,
>> design-wise? It would be nice to also support client auth, and not
>> just the standard server validation SSL test.
> David, some questions/suggestions if I may?
> I see from the URL which you posted to sks-devel:
> that you're using:
> How is this expected to interact with keyserver pools? Should every
> server know every pool which $random_people construct and include it
> subjectAltName? How about certificate validation for that case?
It's an interesting question. To a certain degree, this isn't GnuPG's
problem. If the server presents a certificate where neither the
common name or the subject alternate name match the name used to
connect, the connection should (and will) fail. Curl handles all that
for us automatically.
Managing those certificates is, as you point out, fairly ugly from the
server operator's point of view...
> If instead we can establish that from day 1, hkps clients *will* use
> then we can then just leave it to the PGP keyservers to develop nice
> admin interfaces for managing the collections of certs which a given
> keyserver will use.
I'm not against this, but there are a few practical caveats. Libcurl
added SNI support around a year ago in 7.18.1 (assuming of course
that the backend crypto library supports it). A year isn't very long
at all, so there are loads of libcurl installations that don't yet
have the proper version of libcurl (and/or openssl, etc). On those
systems, we (meaning libcurl, really) can only do common name and
subject alternate name checks. The three systems I just checked had
libcurl 7.16.3 (no SNI), 7.19.4 (SNI), and 7.15.5 (no SNI). That does
not bode well for quick adoption.
By all means, have the servers provide the right info though. The
clients will eventually catch up. This doesn't require any code
change to GPG - if libcurl supports SNI, then GPG does too. If GPG
doesn't support SNI, and the server presents the wrong certificate,
the request will fail. No real harm, since that is what would have
happened anyway if the server didn't support SNI.
Having said all that, I'm not sure if all this peer validation isn't a
bit of overkill. My main desire for hkps is that the data on the wire
is encrypted to avoid casual snooping, and you don't need any peer
validation for that.
Anyway, I might feel differently if it required a major code
commitment in GPG, but as things stand now, if the keyserver operators
want to band together and make sure their servers have a particular
cert setup and make the proper cainfo data available for clients who
want to use it, why not?
More information about the Gnupg-devel