bug: dirmngr latches SRV port cross-scheme
Closed, ResolvedPublic

Description

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.

Reproducing

% 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]

Logs

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

Setup

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; meanwhile :11374 is non-TLS. These were done for testing SRV for other bug-reports.

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.

syscomet created this task.Apr 4 2017, 1:44 AM
syscomet created this object in space S1 Public.
syscomet set Version to GnuPG 2.1.19.
justus triaged this task as Normal priority.Jun 8 2017, 3:01 PM
justus added a project: gnupg (gpg22).
justus claimed this task.Jun 20 2017, 12:41 PM
werner reopened this task as Open.Jun 23 2017, 12:14 PM
werner added a project: Testing.
werner added a subscriber: werner.

This is such a large change that I feel uneasy to close the bug before we know that there are no regressions. This Means we need to wait whether the next release will break.

justus removed justus as the assignee of this task.Jun 26 2017, 10:53 AM
justus added a subscriber: justus.
marcus added a subscriber: marcus.EditedJun 27 2017, 11:16 AM

@werner An open ticket should mean there is something that can be acted upon. Unless you are saying that we should actively look for regressions or should actively do more testing, this ticket should be closed now. There is plenty of peripheral information that will remind us of this ticket in case more issues resurface related to this change.

Given that we have no TESTING status, the only way I can handle this is by keeping the ticket open and add the TESTING flag. Closing a bug which has not been tested is a bad idea.

What tests do you want to be done?

On Wed, 28 Jun 2017 15:47, noreply@dev.gnupg.org said:

What tests do you want to be done?

Real world tests. Thus we need to do a release to test it.

Salam-Shalom,

 Werner

- {F161345, layout=link}
marcus changed the task status from Open to Testing.Jun 30 2017, 4:35 PM

I added a new task status "Testing".

werner closed this task as Resolved.Nov 5 2018, 9:30 AM
werner claimed this task.

No more complaints thus time to close.