Keyserver/security bug 1447 (and 1446 too)

David Shaw dshaw at
Sun Dec 2 18:57:39 CET 2012

On Dec 2, 2012, at 12:34 AM, Phil Pennock <gnupg-devel at> 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), and resolves to  It then makes a https call to that host, but is using as the SNI, as that matches the host name. You are arguing that it should have used 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.


More information about the Gnupg-devel mailing list