Keyserver/security bug 1447 (and 1446 too)

[Phil Pennock]

Hi, wondering if the bug-tracker is considered stale and the devel
mailing-list is preferred, as there's been no reaction to a security
impacting bug (1447) while the lesser 1446 which was mentioned on-list
did get a response.

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.

https://bugs.g10code.com/gnupg/issue1447
  TLS hostname selection uses insecure SRV data

Unless DNSSEC is used and verified by a validating recursor, it's
definitely wrong to be using identities from DNS for presentation.
Instead, the name configured for GnuPG (in the trusted config) should be
used for verifying identity.

If this is fixed, then PGP keyserver pool-maintainers can sensibly issue
TLS certs to be used by individual keyservers and have clients verify
correctly.  This affects "hkps.pool.sks-keyservers.net" and is the
reason that there are currently no SRV records published.

With the CA cert from:
  <http://www.sks-keyservers.net/overview-of-pools.php>
and forcing the pool to resolve to my host, I can confirm this presents
the correct certificate:

$ curl \
  --cacert ~/.gnupg/CA/sks-keyservers.netCA.pem \
  --resolve "hkps.pool.sks-keyservers.net:443:94.142.241.93" \
  -sv "https://hkps.pool.sks-keyservers.net/pks/lookup?op=stats" >/dev/null

Hopefully it's clear that, until that certificate verification works in
GnuPG (--keyserver-option check-cert left on), something is going wrong
with the names that GnuPG is presenting to keyservers.


The other bug affects keyserver interop and did get commented upon; if
it can be fixed in the same release as the 1447 bug, then we keyserver
operators will know that any client that can validate identity can use
ports from SRV records and not have to worry as much about older clients
which can't verify anyway.

https://bugs.g10code.com/gnupg/issue1446
  hkps SRV lookup discards port from SRV

The code I pointed to is apparently not the current code, but the flaw
remains present, with the same impact.

Thanks,
-Phil