Keyserver/security bug 1447 (and 1446 too)

[David Shaw]

On Dec 2, 2012, at 12:34 AM, Phil Pennock <gnupg-devel at spodhuis.org> wrote:

> This first bug (1447) is a security-impacting bug; not too bad, since
> PGP has message-level security, so the key data isn't impacted, but it
> does permit MitM attacks for discerning what's happening.  GnuPG uses
> data from insecure DNS for presenting to an HTTPS-enabled keyserver as
> TLS SNI and for verifying certificates.  So if DNS responses are
> tampered with, the injected bad server will verify fine for the client.

Allow me to restate the problem to make sure I understand what you're saying. GnuPG does a SRV lookup for hkps under (for example) my-hkps-pool.example.com, and resolves to some-keyserver-in-the-pool.example.net.  It then makes a https call to that host, but is using keyserver-in-the-pool.example.net as the SNI, as that matches the host name. You are arguing that it should have used my-hkps-pool.example.com as the SNI?

If that's the issue, I agree that is not ideal. It's sort of a side effect of how we're doing SRV with Curl. Since Curl doesn't do SRV at all, we have a wrapper around libcurl that does a minimal emulation of true SRV and then forces the URL to be what it should be, according to the SRV.

As far as I know, libcurl uses the host from the passed-in URL for SNI and there isn't a direct option to set the SNI to an arbitrary value, but looking at the options, CURLOPT_RESOLVE could be used to fix this by feeding in a record with the pool name and the address of the chosen server.

Ideally, libcurl would handle SRVs internally, but that's a problem and solution of a different order.

David