HKP keyservers over TLS [was: Re: HKP keyservers over SSL]

Daniel Kahn Gillmor dkg at
Fri Mar 13 14:09:44 CET 2009

On 03/12/2009 06:20 PM, David Shaw wrote:
> Curl takes care of a huge amount of
> annoyance for us.  If we needed some special TLS code in Curl, instead
> of doing something GPG-specific, it would be cleaner all around to
> implement the code in a general fashion and just give it to the Curl
> folks.

Yes, this does seem like a better way to go, if we can frame our changes
in such a way that the curl folks are receptive

> Tell me a bit about how you rigged up the SSLized sks server (it's a
> wrapper, no?)  Let's say for the sake of argument that curl supported
> TLS upgrade (it doesn't - but let say it did).  How difficult would it
> be to you to support it in sks?

At the moment, we're just running an nginx proxy as a TLS-based
frontend, talking to SKS which is listening on the loopback.

nginx configuration details are here:

It does *not* currently support TLS upgrade. As you said earlier, RFC
2817 never seemed to have caught on.  I don't know what it would take to
support it, either in sks directly, or by hacking together some other
reverse proxy as a frontend.  A brief review of the popular free tools
capable of acting as reverse HTTP/HTTPS proxies (nginx, squid, varnish,
pound) doesn't show any of these tools offering TLS Upgrade support.  I
suspect this is something that would need to be hacked together within SKS.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090313/7133432b/attachment.pgp>

More information about the Gnupg-devel mailing list