HKP keyservers over SSL
dshaw at jabberwocky.com
Thu Apr 2 13:45:37 CEST 2009
On Apr 2, 2009, at 12:15 AM, Phil Pennock wrote:
> 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
>> not bode well for quick adoption.
> hkps support is not out there now. If hkps support means, in
> SNI support, then operators can rely upon this. If it doesn't, we're
> just perpetuating the continued poor state of affairs.
I quite agree. It's just that SNI support in libcurl and friends does
not yet exist in sufficient percentage of the "market". We can't make
the hkps==SNI guarantee. We can strongly suggest it, and we will
eventually get there once the newer libraries percolate through the
world, but it's not a guarantee we can make today.
> 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
> this support is not present?
I'm okay with this, except there isn't a good way to tell this at
compile (or even run) time. SNI in curl is hidden fairly deep under
the covers. Even if I do the inadvisable thing and warn for any
version of curl older than 7.18.1, that doesn't really give a reliable
answer, as curl might be linked against a SSL library that doesn't
>> 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
>> 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
> 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.
Oh, don't get me wrong: verification exists in the code today. It's
even on by default (another example of a least-unhappy choice). I'm
just pointing out that it's not my main desire. If it meets someone
else's desire, that's great, though. I'm not writing this for me
More information about the Gnupg-devel