HKP keyservers over SSL
gnupg-devel at spodhuis.org
Thu Apr 2 06:15:15 CEST 2009
On 2009-04-01 at 22:42 -0400, David Shaw wrote:
> 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.
hkps support is not out there now. If hkps support means, in practice,
SNI support, then operators can rely upon this. If it doesn't, we're
just perpetuating the continued poor state of affairs.
How about some notes on this in the README's "BUILD INSTRUCTIONS"
stating pretty much what you just said and strongly recommending this?
Ideally with ./configure CAPS WARNINGS if hkps support is requested but
this support is not present?
(I'm not requesting work of others and doing nothing myself; I worked on
better SNI support in a variety of tools yesterday and am planning on
extending the Perl/Python patches today/tomorrow to include server-side
> 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.
When some hotel or wifi AP has played funny buggers with DNS because
they don't understand that Internet != Web, it's useful to have tools
gracefully report the problem. I like it when tools are able to report
that the problems are because it couldn't actually get an unmolested
connection to the server, rather than something else being wrong. So if
verification is a simple enough hack, I'm all for it.
> 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?
Okay, once SKS 1.1.1 is out with IPv6 support, my next patching effort
there is likely to involve TLS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 163 bytes
Desc: not available
More information about the Gnupg-devel