2.0.20 breaks DNS SRV hkp keyserver access via web proxy server

[David Shaw]

On Jun 11, 2013, at 5:25 PM, John Marshall <john.marshall at riverwillow.com.au> wrote:

> On Tue, 11 Jun 2013, 08:33 -0400, David Shaw wrote:
>> On Jun 10, 2013, at 6:33 AM, John Marshall <john.marshall at riverwillow.com.au> wrote:
>> 
>>> The "SNI" changes to gnupg's handling of DNS SRV keyserver records means
>>> that a client accessing an hkp keyserver via a web proxy server can no
>>> longer contact the selected target keyserver.
>>> 
>>> In 2.0.19, the target host from the SRV list would be selected and the
>>> HTTP query would be addressed to that target host domain.  In 2.0.20,
>>> the target host is selected, its address looked up, a fake record
>>> constructed comprising the SRV record owner's domain name (not the SRV
>>> target's domain name) and the query is constructed using the SRV
>>> record owner's domain as the host part.  Although not following the
>>> intention of RFC2782, this works fine for a directly-connected client
>>> because the IP address of the selected target is used.  However, in the
>>> case of a client behind a web proxy, the fake (SRV RR owner) domain is
>>> used as the hostname in the query and passed to the web proxy server.
>>> If the SRV RR owner also has an A or AAAA record, that (rather than
>>> whatever address was selected by gnupg) will be used by the proxy server
>>> to contact what may or may not be a keyserver.  If there is no A record
>>> in the SRV RR owner domain, the proxy server returns an error to gnupg.
>>> Either way it's broken.
>> 
>> I think I'm following what the problem is here.  Can you confirm something :  Are you using the libcurl support in GnuPG, or the built-in HTTP support?
> 
> We are using --with-libcurl=/usr/local because we want the SRV support.
> (see my earlier post on the battle I had getting --with-libcurl=PATH to
> detect curl-config)
> 
>> I suspect you are using libcurl, and I can see how you would get exactly the behavior you describe.  Out of curiosity, if you are indeed using libcurl, can you try the built-in HTTP support and see if that works better (i.e. properly) for you?  Just build with "./configure --without-libcurl"
> 
> ?? I can't see how --without-libcurl does any SRV processing at all

It does.  Both --with-libcurl and --without-libcurl have SRV support.  For the libcurl version, it's faked from the outside.  For the without-libcurl version, the built-in HTTP engine actually supports SRV natively.  That it doesn't work on either path is for a different reason on each path.

I'm not convinced that it makes sense for a client to resolve the SRV, and then pass the resulting hostname to a proxy.  For example, leaving aside SRV, the client does not try and resolve an A record or chase a CNAME, but rather passes the requested resource to the proxy and the proxy does the work translating that to a DNS name, looking up that name, making the connection, etc.  Indeed, the client may not even be able to resolve external DNS at all.

It's true this worked in a previous version of GnuPG, but this was due to an incorrect implementation in GPG and the way your DNS and proxy is set up.  It was basically doing part of the DNS work in the client, and then passing the intermediate result to the proxy to do the rest, sort of like a DNS-level redirect, which as you point out does not follow the intent of RFC2782.

One thing you might do is "keyserver-options no-try-dns-srv", but even that won't really help with names like "au.gnupg.net".  A SRV-only keyserver name isn't going to work properly with a proxy.

David