2.0.20 breaks DNS SRV hkp keyserver access via web proxy server
John Marshall
john.marshall at riverwillow.com.au
Tue Jun 11 23:25:44 CEST 2013
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 -
but I've tested for you anyway (see below) and, no, it doesn't work. We
need libcurl because we need the SRV processing and we need it to return
the domain name of the selected target to pass to the proxy server.
It seems that my problem description is not sufficiently clear. I was
hoping there would be no need to post explicit examples but...
gnupg 2.0.20 (curl-shim)
========================
rwpc13> gpg --keyserver hkp://au.gnupg.net --keyserver-options 'http-proxy=http://cache1.mby.riverwillow.net.au:3128 debug' --search-keys 0xA29A84A2
gpg: searching for "0xA29A84A2" from hkp server au.gnupg.net
gpgkeys: curl version = GnuPG curl-shim
gpgkeys: search type is 5, and key is "A29A84A2"
* HTTP proxy is "http://cache1.mby.riverwillow.net.au:3128"
* HTTP URL is "http://au.gnupg.net:11371/pks/lookup?op=index&options=mr&search=0xA29A84A2"
* SRV tag is "pgpkey-http": host and port may be overridden
* HTTP auth is "null"
* HTTP method is GET
gpg: key "0xA29A84A2" not found on keyserver
rwpc13>
gnupg 2.0.20 (libcurl)
======================
rwpc13> gpg --keyserver hkp://au.gnupg.net --keyserver-options 'http-proxy=http://cache1.mby.riverwillow.net.au:3128 debug' --search-keys 0xA29A84A2
gpg: searching for "0xA29A84A2" from hkp server au.gnupg.net
gpgkeys: curl version = libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.7
gpgkeys: Faking pgpkey-http SRV from au.gnupg.net to svcs4.riverwillow.net.au:11371
gpgkeys: search type is 5, and key is "A29A84A2"
* Added au.gnupg.net:11371:202.125.45.72 to DNS cache
* About to connect() to proxy cache1.mby.riverwillow.net.au port 3128 (#0)
* Trying 172.25.24.28...
* connected
* Connected to cache1.mby.riverwillow.net.au (172.25.24.28) port 3128 (#0)
> GET http://au.gnupg.net:11371/pks/lookup?op=index&options=mr&search=0xA29A84A2 HTTP/1.1
Accept: */*
Proxy-Connection: Keep-Alive
Host: au.gnupg.net
Pragma: no-cache
Cache-Control: no-cache
< HTTP/1.1 503 Service Unavailable
< Server: squid/3.3.5
< Mime-Version: 1.0
< Date: Tue, 11 Jun 2013 21:02:46 GMT
< Content-Type: text/html
< Content-Length: 3486
< X-Squid-Error: ERR_DNS_FAIL 0
< Vary: Accept-Language
< Content-Language: en
< X-Cache: MISS from cache1.mby.riverwillow.net.au
< Via: 1.1 cache1.mby.riverwillow.net.au (squid/3.3.5)
< Connection: keep-alive
<
* Connection #0 to host cache1.mby.riverwillow.net.au left intact
* Closing connection #0
gpg: key "0xA29A84A2" not found on keyserver
rwpc13>
gnupg 2.0.19 (libcurl)
======================
rwpc13> gpg --keyserver hkp://au.gnupg.net --keyserver-options 'http-proxy=http://cache1.mby.riverwillow.net.au:3128 debug' --search-keys 0xA29A84A2
gpg: searching for "0xA29A84A2" from hkp server au.gnupg.net
gpgkeys: curl version = libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.7
gpgkeys: search type is 5, and key is "A29A84A2"
* About to connect() to proxy cache1.mby.riverwillow.net.au port 3128 (#0)
* Trying 172.25.24.28...
* connected
* Connected to cache1.mby.riverwillow.net.au (172.25.24.28) port 3128 (#0)
> GET http://svcs4.riverwillow.net.au:11371/pks/lookup?op=index&options=mr&search=0xA29A84A2 HTTP/1.1
Host: svcs4.riverwillow.net.au:11371
Accept: */*
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
< HTTP/1.1 200 OK
< Date: Tue, 11 Jun 2013 21:07:16 GMT
< Server: sks_www/1.1.4
< Cache-Control: no-cache
< Pragma: no-cache
< Expires: 0
< Content-Length: 111
< X-HKP-Results-Count: 1
< Content-Type: text/plain
< X-Cache: MISS from svcs4.riverwillow.net.au
< X-Cache: MISS from cache1.mby.riverwillow.net.au
< Via: 1.1 svcs4.riverwillow.net.au (squid/3.3.5), 1.1 cache1.mby.riverwillow.net.au (squid/3.3.5)
< Connection: keep-alive
<
* Connection #0 to host cache1.mby.riverwillow.net.au left intact
* Closing connection #0
(1) John Marshall <john.marshall at riverwillow.com.au>
1024 bit DSA key A29A84A2, created: 2008-05-03
Keys 1-1 of 1 for "0xA29A84A2". Enter number(s), N)ext, or Q)uit > q
rwpc13>
Thank you for taking the time to look at this problem report.
--
John Marshall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: </pipermail/attachments/20130612/39107956/attachment-0001.sig>
More information about the Gnupg-devel
mailing list