dkg at fifthhorseman
Mar 13, 2009, 6:09 AM
Post #1 of 1
(488 views)
Permalink
|
|
HKP keyservers over TLS [was: Re: HKP keyservers over SSL]
|
|
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
|
signature.asc
