Bug: dirmngr latches SRV port cross-scheme

[Phil Pennock]

If using SRV records for a hostname, GnuPG 2.1.19 is now trying to use
`_pgpkey-http` and `_pgpkey-https` as SRV lookups, which is great.

The result is cached as part of the record for the hostname.

So if you use hkp://foo and then hkps://foo then the SRV result for
_pgpkey-http is used for hkps: instead of picking up the _pgpkey-https
result.  These should normally be expected to be different ports, rather
than sharing.

Not currently diving into the DNS/dirmngr internals to tackle this,
hoping this, and the appropriate test resources below, are enough to
help?

Below:
 * commands to reproduce
 * dirmngr log (debug 1024)
 * details of the setup

The setup is dual-cert RSA and ECC for "keyserver.spodhuis.org" as part
of my testing how well this might work with clients.

Thanks,
-Phil

% gpg --keyserver hkp://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04
[success]
% gpg --keyserver hkps://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04
gpg: refreshing 1 key from hkps://keyserver.spodhuis.org
gpg: keyserver refresh failed: No keyserver available
% gpgconf --kill dirmngr
% gpg --keyserver hkps://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04
[success]

2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> S KEYSERVER hkp://keyserver.spodhuis.org
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> OK
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04
2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> S SOURCE http://keyserver.spodhuis.org:11374
2017-03-31 16:25:49 dirmngr[22935.6] DBG: (104202 bytes sent via D lines not shown)
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> OK
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 <- BYE

2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.spodhuis.org
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> OK
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KEYSERVER
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> S KEYSERVER hkps://keyserver.spodhuis.org
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> OK
2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04
2017-03-31 16:25:54 dirmngr[22935.6] TLS handshake failed: An unexpected TLS packet was received.
2017-03-31 16:25:54 dirmngr[22935.6] error connecting to 'https://keyserver.spodhuis.org:11374': Network error
2017-03-31 16:25:54 dirmngr[22935.6] marking host 'keyserver.spodhuis.org' as dead
2017-03-31 16:25:54 dirmngr[22935.6] host 'keyserver.spodhuis.org' marked as dead
2017-03-31 16:25:54 dirmngr[22935.6] command 'KS_GET' failed: No keyserver available
2017-03-31 16:25:54 dirmngr[22935.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2017-03-31 16:25:54 dirmngr[22935.6] DBG: chan_6 <- BYE

2017-03-31 16:26:13 dirmngr[22935.6] DBG: chan_6 <- KILLDIRMNGR

2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.spodhuis.org
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> OK
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KEYSERVER
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> S KEYSERVER hkps://keyserver.spodhuis.org
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> OK
2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04
2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known]
2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 -> S SOURCE https://keyserver.spodhuis.org:11373
2017-03-31 16:26:17 dirmngr[22948.6] DBG: (104202 bytes sent via D lines not shown)
2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 -> OK
2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 <- BYE


The hostname "keyserver.spodhuis.org" has both sets of SRV records, on
non-standard ports; this hostname is an alias for "sks.spodhuis.org"
(same backend SKS keyserver) but different nginx server stanzas in front
of it.  I set this up in Dec 2012 and "keyserver" as a hostname is
primarily for testing by me.

The normal :443 port serves with SNI to select between the sks-keyservers.net
CA-issued cert for pool hostnames (pool.sks-keyservers.net
*.pool.sks-keyservers.net) and a Let's Encrypt cert for
"sks.spodhuis.org" itself.  For "keyserver.spodhuis.org", the HTTPS
cert still uses my own private CA.  This is on the normal :443 port and
also :11373; :11374 is non-TLS.

DNS:
_pgpkey-http._tcp.keyserver     IN      SRV     10 10 11374     keyserver
_pgpkey-https._tcp.keyserver    IN      SRV     10 10 11373     keyserver

Today I refreshed the HTTPS certs used for "keyserver", to make them
dual RSA+ECDSA.  I then tried to test how this worked with GnuPG and ran
smack into this problem.

The certs used for "keyserver.spodhuis.org" are issued from the two
roots at:
  https://www.security.spodhuis.org/

"globnixCA4" is an RSA-based root issuing certs for RSA keys.
"globnixCA5" is an ECC CA, on secp384r1, issuing certs for ECDSA keys.

I run with ~/.gnupg/dirmngr.conf specifying:
  hkp-cacert /Users/pdp/.gnupg/CA/hkp-cacerts.pem
(and equiv /home for other systems) and that file containing Kristian's
sks-keyservers.net root, my own roots and the Let's Encrypt roots.

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: </pipermail/attachments/20170331/ae41cb25/attachment-0001.sig>