2.0.20 breaks DNS SRV hkp keyserver access via web proxy server

[John Marshall]

Sorry.  It hadn't occurred to me that the Subject of my post may have
been ambiguous.  I am talking about the gnupg client's local web proxy
server, not a remote reverse proxy sitting in front of a keyserver.

 $ gpg --keyserver hkp://example.com \
       --keyserver-options 'http-proxy=http://proxy.local.network:3128' \
       ...
 (where the _pgpkey-http._tcp.example.com. label has SRV RR's; and
  where the example.com. label does not necessarily have any A or AAAA
  RR's)

On Mon, 10 Jun 2013, 19:15 -0400, Phil Pennock wrote:
> On 2013-06-10 at 20:33 +1000, John Marshall 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.

This is the important bit.  The gnupg client can no longer reliably (if
at all) access the SRV-derived keyserver host via its local proxy.  It
may happen to contact some other keyserver or the proxy may just return
an error (e.g. no address record for that domain), because the domain
name being passed to the local proxy server (for the proxy to resolve to
an IP address and connect) is the domain name of the SRV record's owner,
not the domain name of the SRV target host.

> The changes were explicitly requested by those of us in the SKS
> operational community working on pool infrastructure, to make sure that
> link security can work with pools and in the presence of DNS attacks,
> but without requiring DNSSEC -- at this point in time, DNSSEC is a
> worthy goal (and something I'm pushing towards elsewhere) but to mandate
> it as the only approach to verifiable link security would be washing our
> hands of a problem.
> 
> If there is to be validation, the SNI and the Host: header have to match
> the identity that is validated.  In the absence of DNSSEC validation,
> the only available non-compromisable input is the original domain name.
> This is what led to the criteria for hkps.pool.sks-keyservers.net
> outlined at <http://www.sks-keyservers.net/overview-of-pools.php>.

Explaining why the change was introduced is helpful and of great
interest to me.  I really appreciate you taking the time to go into that
detail (and the detail below).  Obviously the hkps/SNI link-security
goals were the focus and the proxy-related hkp(s) breakage was not
intentional.

> >                                                         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 you use a dedicated port (11373 is spreading a little for hkps) then
> you can default all handling through to the correct default vhost, and
> put the port into the SRV record.  That way, things that don't
> understand SRV will send the hostname you are expecting, and things that
> do understand SRV will connect to the correct port.
> 
> The other alternative is to list hostnames for known pools/domains that
> you serve for, so that you're not serving for unknown domains, which is
> a common operational security stance.
> 
> So, you then need a certificate for the original domain, or to disable
> verification.  Using the hostname is equivalent to disabling
> verification, because the hostname is derived insecurely, but the
> problem can be "hidden" so that folks don't recognise the attack vector.
> 
> Getting a certificate for the original domain means talking to whomever
> controls the domain.  If it's not your domain and the operator doesn't
> want to help sort out certs, then you simply don't offer hkps for that
> domain, only for your own.
> 
> The link above includes instructions for how SKS keyserver operators can
> get a certificate under a trust anchor available for sks-keyservers.net.
> There's no sane way to manage this within the traditional PKIX because
> no Certificate Authority is going to issue multiple certs for the same
> name to different operators, and reusing keys between independently
> operated keyservers would be a security joke.

Thanks for the keyserver reverse-proxy hkps tips - but that wasn't the
point of my post.

> > I am not a programmer and I don't speak C but I have made a little hack
> > to keyservers/gpgkeys_hkp.c to get us operational again.  This is
> 
> Unfortunately, you've moved things back to a state where the client is
> verifying that the delivered certificate has a hostname that was
> retrieved over insecure DNS, introducing a security hole back into the
> client.

It's not a solution, it's a quick and nasty hack by a non-programmer so
that clients can talk to an off-LAN hkp keyserver.  I'm looking for help
to find a proper solution.  For example:

 - a patch to change the default back to constructing the query using
   the SRV target's domain name UNLESS a --use-sni-srv-hack option is
   set AND the specified keyserver scheme is hkps://.

 - even just a patch that restores proper SRV handling for the hkp://
   scheme would be appreciated.

> To safely do what you've done, you'd also have to add DNSSEC
> verification.
> 
> Really, you might as well use `--keyserver-options no-check-cert` since
> that's the security you're really getting, using the patch you provide.

We do use validating resolvers but we've never actually used hkps.  As
far as I can see, this hkps/SNI modification provides no benefit at all
for hkp - only proxy breakage.

> > Is anyone able to suggest a better/safer patch for us - or better still,
> > a proper solution to this problem that can be used as a patch in
> > downstream ports?
> 
> The most proper solution is for DNSSEC to be deployed everywhere today.
> In the absence of that, HKPS support has moved towards verifying the
> domain.
> 
> Ultimately, with DNSSEC the way back out of this is with DANE and
> <http://tools.ietf.org/html/draft-ietf-dane-srv-02>.
> 
> For HKPS the solution would then be:
> 
>  * if no DNSSEC validation available, use the 2.0.20 logic
>  * if DNSSEC insecure, use the 2.0.20 logic
>  * if DNSSEC validates as secure, then check for a TLSA record for the
>    members of the SRV pool
>    * if TLSA record found, use the derived hostname for checks
>    * if TLSA record not found, use the 2.0.20 logic
> 
> This gives as much security as is possible to each client and the
> operator of the _target_ host can decide for themselves which hostname
> should be validated, since they're presumably in control of the DNS for
> the target domain (and can chop out support of pools which rename to
> their own hostname).

For what it's worth, I think that if the DNSSEC/DANE solution is the 
correct one, then implementing that is the best way to encourage its
adoption.  The current hkps/SRV/SNI solution really seems to me like
taking a chisel to the round hole in order to try to make the square peg
fit.

Thanks, Phil, for the pointer to the DANE SRV document.  I think that's
really exciting stuff.

-- 
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/20130611/38df60e8/attachment.sig>