Keyserver/security bug 1447 (and 1446 too)

[David Shaw]

On Dec 3, 2012, at 7:57 AM, Werner Koch <wk at gnupg.org> wrote:

>> poisoned. As long as no CAs are activated by default this will be less
>> of an issue (as the cert check should fail), but as soon as someone
>> package curl / any client with some pre-defined root CAs, "any" server
>> can take over the request.
> 
> Right.  Given that HKPS is not yet widely used (right?), what about
> setting this up correctly than eventually ending up with jumble of
> different schemes?
> 
> Requiring that the poolname is also in the keyserver's certificate,
> seems to be the easiest scheme.  With 2.1 it will be pretty easy to
> implement any kind of certificate validation.  We could even provide
> default certificates for a number of different pools [1].  I am not keen
> to implement that for 2.0, with the keyserver helpers and TLS support
> only via Curl.

I think it's reasonable to leave future enhancements like default certificates to 2.1, but I also think we need to make at least a minimal fix in 2.0 as it is actively doing the wrong thing by passing the wrong SNI and Host header so can't readily interoperate with what will come later in 2.1.

How about this: we fix 1447 in 2.0 only by passing the correct Host header (for both curl-shim and real curl) and SNI for real curl.  This is very simple to do in the curl-shim, and only slightly more messy for the real curl.  Issue 1446 should just be fixed (I'm testing a fix for this already) - it's a straightforward bug.

David