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

[Daniel Kahn Gillmor]

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:

  http://lists.gnu.org/archive/html/sks-devel/2009-03/msg00029.html

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.

	--dkg

-------------- 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>