HKP keyservers over SSL

[David Shaw]

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,  
>> gpgsm
>> 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:
>  http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/keyserver/gpgkeys_hkp.c?root=GnuPG&rev=4924&r1=4878&r2=4924
> that you're using:
>  curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,(long)opt- 
> >flags.check_cert);
>
> How is this expected to interact with keyserver pools?  Should every
> server know every pool which $random_people construct and include it  
> in
> 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  
> SNI
> 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?

David