Locating Keys via WKD with gpg4win fails with unknown error.
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	mieth
	Feb 2 2022, 10:52 AM

Description

Trying to locat or fetch a public key with WKD fails with an "unknwon error" in Windows Environments, while it works within MacOS and Linux Environments.

C:\Users\User>gpg --locate-keys --auto-key-locate clear,nodefault,wkd mail@DOMAIN
gpg: Fehler beim automatischen holen von `mail@DOMAIN' über `WKD': Unknown error
gpg: error reading key: Unknown error

The problem occours up to Windows 11 Pro 21H2 Build 22000.438, and

C:\Users\User>gpg --version
gpg (GnuPG) 2.3.4
libgcrypt 1.9.4
Copyright (C) 2021 g10 Code GmbH
License GNU GPL-3.0-or-later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: C:\Users\User\AppData\Roaming\gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

AEAD: EAX, OCB
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

from gpg4win 4.0.0

The problem is reported at least since 2019, see https://www.kuketz-blog.de/gnupg-web-key-directory-wkd-einrichten/#comment-51597

I was not able, to find this error within the bugtracker.
Without solving it, it is nearly impossible to implement wkd within the german public administration, as suggested by the BSI, see https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Freie-Software/E-Mail-Verschluesselung/EasyGPG/easygpg.html?nn=129212#doc432800bodyText7

Details

Version: 4.0.0

Revisions and Commits

rT Not Too Bad TLS
	rT08c1622944da Allow ephemeral ECDSA cipher suites.

Related Objects

Mentioned Here: T4597: Support GCM modes for ntbtls.

Event Timeline

mieth created this task.Feb 2 2022, 10:52 AM

Check that the server does not prohibit TLS 1.2 - a few server admins allow only TLS 1.3 for whatever security threats they have in mind.

The server in the testcase is wkd.keys.openpgp.org which is referred with CNAME via the DNS. Referring to https://www.ssllabs.com/ssltest/analyze.html?d=wkd.keys.openpgp.org it shoud support TLS 1.2

(In addition, TLS 1.3 support would of course also be desirable.)

By the way:
The CNAME could cause problems with the certificate.
Concrete examples possible via DM.

After further testing: The error does not occur if WKD is implemented directly under the respective domain.
The behavior of GnuPG differs between Windows and other platforms. However, it is not clear to me which version is behaving incorrectly. But it seems clear that there is no compatibility with the instructions at https://keys.openpgp.org/about/usage#wkd-as-a-service under Windows. (However this may concern another project.)

Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?

Either way, I hadn't considered this for the WKD relay. I'll look into enabling AES-CBC there, at least for backwards compatibility.

In T5813#154552, @Valodim wrote:

Might be an issue with matching ciphersuites? There was a problem with this before when GnuPG didn't support AES-GCM yet (https://dev.gnupg.org/T4597). That was added in 2020, maybe it's not rolled out far enough yet?

Either way, I hadn't considered this for the WKD relay. I'll look into enabling AES-CBC there, at least for backwards compatibility.

I thank you for your efforts!
Unfortunately, the error pattern has so far remained unchanged on the Windows systems from which I can get test data.

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

In T5813#154705, @bernhard wrote:

@mieth can you enable the dirmngr log and give it more message, you'll be able to diagnose the problem further. There have been problems in the past with the contents of the certificate store of Windows. It does not look like this is the problem you are facing, but the diagnostic messages should be helpful.

I'm not sure if I understood the request correctly, but I started the "dirmngr" as a service and had a log written and made the request again via gnupg. Both programms were asked to be verbose. The following are the logs cleaned of personal data:

dirmngr log:

2022-02-08 13:29:06 [36944]    dauerhaft geladene Zertifikate: 73
2022-02-08 13:29:06 [36944]  zwischengespeicherte Zertifikate: 0
2022-02-08 13:29:06 [36944]     vertrauenswürdige Zertifikate: 73 (73,0,0,0)

gnupg log:

2022-02-08 13:30:41 gpg[35180] Note: RFC4880bis features are enabled.
2022-02-08 13:30:41 gpg[35180] enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
2022-02-08 13:30:41 gpg[35180] DBG: [no clock] start
2022-02-08 13:30:41 gpg[35180] verwende Vertrauensmodell pgp
2022-02-08 13:30:41 gpg[35180] DBG: chan_0x00000288 <- # Home: C:\Users\User\AppData\Roaming\gnupg
2022-02-08 13:30:41 gpg[35180] DBG: chan_0x00000288 <- # Config: C:/Users/User/AppData/Roaming/gnupg/dirmngr.conf
2022-02-08 13:30:41 gpg[35180] DBG: chan_0x00000288 <- OK Dirmngr 2.3.4 at your service
2022-02-08 13:30:41 gpg[35180] DBG: connection to the dirmngr established
2022-02-08 13:30:41 gpg[35180] DBG: chan_0x00000288 -> GETINFO version
2022-02-08 13:30:41 gpg[35180] DBG: chan_0x00000288 <- D 2.3.4
2022-02-08 13:30:41 gpg[35180] DBG: chan_0x00000288 <- OK
2022-02-08 13:30:41 gpg[35180] DBG: chan_0x00000288 -> WKD_GET -- mail@domain.de
2022-02-08 13:30:41 gpg[35180] DBG: chan_0x00000288 <- S SOURCE https://openpgpkey.domain.de
2022-02-08 13:30:56 gpg[35180] DBG: chan_0x00000288 <- ERR 167805060 Unknown error <Dirmngr>
2022-02-08 13:30:56 gpg[35180] Fehler beim automatischen holen von `mail@lwmieth.de' über `WKD': Unknown error
2022-02-08 13:30:56 gpg[35180] error reading key: Unknown error
2022-02-08 13:30:56 gpg[35180] DBG: chan_0x00000288 -> BYE
2022-02-08 13:30:56 gpg[35180] DBG: [no clock] stop
2022-02-08 13:30:56 gpg[35180] keydb: handles=0 locks=0 parse=0 get=0
2022-02-08 13:30:56 gpg[35180]        build=0 update=0 insert=0 delete=0
2022-02-08 13:30:56 gpg[35180]        reset=0 found=0 not=0 cache=0 not=0
2022-02-08 13:30:56 gpg[35180] kid_not_found_cache: count=0 peak=0 flushes=0
2022-02-08 13:30:56 gpg[35180] sig_cache: total=0 cached=0 good=0 bad=0
2022-02-08 13:30:56 gpg[35180] objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0
2022-02-08 13:30:56 gpg[35180] objcache: uids=0/0/0 chains=0,0..0 buckets=0/0
2022-02-08 13:30:56 gpg[35180] random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
2022-02-08 13:30:56 gpg[35180] rndjent stat: collector=0x00000000 calls=0 bytes=0
2022-02-08 13:30:56 gpg[35180] secmem usage: 0/32768 bytes in 0 blocks

You may have to restart the dirmngr to see the log-file option be honored. The gpg request to dirmngr should be visible in the log.

Add the following to dirmngr.conf:

debug ipc,dns,network,lookup

There are more debug flags but the above flags should cover anything related to the lookup.

2022-02-10 17:07:35 [12256]    dauerhaft geladene Zertifikate: 74
2022-02-10 17:07:35 [12256]  zwischengespeicherte Zertifikate: 0
2022-02-10 17:07:35 [12256]     vertrauenswürdige Zertifikate: 74 (74,0,0,0)
2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> # Home: C:\Users\User\AppData\Roaming\gnupg
2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> # Config: .\dirmngr.conf
2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> OK Dirmngr 2.3.4 at your service

Did you make another request for locating keys via WKD after adding the debug flags? I'm asking because when I do this I get the following log:

2022-02-10 17:49:59 dirmngr[6780] listening on socket '/run/user/1000/gnupg/d.f3hdqcrmjwf98p87yqjmuctx/S.dirmngr'
2022-02-10 17:49:59 dirmngr[6781.0] permanently loaded certificates: 130
2022-02-10 17:49:59 dirmngr[6781.0]     runtime cached certificates: 0
2022-02-10 17:49:59 dirmngr[6781.0]            trusted certificates: 130 (130,0,0,0)
2022-02-10 17:49:59 dirmngr[6781.0] failed to open cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt': No such file or directory
2022-02-10 17:49:59 dirmngr[6781.0] creating directory '/tmp/tmp.8P2EakNghu/crls.d'
2022-02-10 17:49:59 dirmngr[6781.0] new cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt' created
2022-02-10 17:49:59 dirmngr[6781.6] handler for fd 6 started
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Home: /tmp/tmp.8P2EakNghu
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Config: /tmp/tmp.8P2EakNghu/dirmngr.conf
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK Dirmngr 2.3.5-beta17 at your service
2022-02-10 17:49:59 dirmngr[6781.6] connection from process 6779 (1000:100)
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- GETINFO version
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> D 2.3.5-beta17
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- WKD_GET -- werner.koch@gnupg.com
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: libdns initialized
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(openpgpkey.gnupg.com): No name
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: getsrv(_openpgpkey._tcp.gnupg.com) -> 0 records
2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> S SOURCE https://gnupg.com
2022-02-10 17:49:59 dirmngr[6781.6] number of system provided CAs: 390
2022-02-10 17:49:59 dirmngr[6781.6] DBG: Using TLS library: GNUTLS 3.7.3
2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:connect_server: trying name='gnupg.com' port=443
2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(gnupg.com): Success
2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:1917:socket_new: object 0x00007f524c290e20 for fd 7 created
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> GET /.well-known/openpgpkey/hu/waoubdep9643akkesx4xm3ynstfffiok?l=werner.koch HTTP/1.0\r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> Host: gnupg.com\r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request-header:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> \r\n
2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:response:
2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> HTTP/1.0 200 OK\r\n
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Date: Thu, 10 Feb 2022 16:49:59 GMT'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Server: Boa/0.94.14rc21'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Accept-Ranges: bytes'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Connection: close'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Length: 957'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Last-Modified: Mon, 28 Jun 2021 17:47:11 GMT'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Type: text/plain'
2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: ''
2022-02-10 17:50:00 dirmngr[6781.6] DBG: (957 bytes sent via D lines not shown)
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 <- BYE
2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK closing connection
2022-02-10 17:50:00 dirmngr[6781.6] handler for fd 6 terminated

@mieth sorry for the delay. meanwhile I adjusted the ciphersuite of the WKD gateway to include an AES-CBC suite. would be interested if it works now on the setup you tested before.

I have the same error when using wkd.keys.openpgp.org with a CNAME DNS entry. The error occurs with Windows 10, 11 and Server 2019 (only the most recent versions tested). With Debian it works fine.

Also with my own WKD (also a Lets's Encrypt certificate) in works on all platforms.

Maybe the following debug-log might help to solve the problem.
The wireshark tcpdump lists the same error (Fatale "Alert"), the connection is terminated before the TLS Handshake is completed. I think the server is terminating the connection.

gpg -vvv --auto-key-locate clear,wkd,nodefault --locate-key test@sanka-gmbh.de
2022-03-29 08:56:24 dirmngr[21676] Es wird auf Socket `C:\\Users\\#name#\\AppData\\Local\\gnupg\\S.dirmngr' gehÃ¶rt
2022-03-29 08:56:24 dirmngr[21676] DBG: Zertifikat `ROOT' ist bereits im Zwischenspeicher
2022-03-29 08:56:24 dirmngr[21676] DBG: Zertifikat `ROOT' ist bereits im Zwischenspeicher
2022-03-29 08:56:24 dirmngr[21676] DBG: Zertifikat `ROOT' ist bereits im Zwischenspeicher
2022-03-29 08:56:24 dirmngr[21676] DBG: Zertifikat `ROOT' ist bereits im Zwischenspeicher
2022-03-29 08:56:24 dirmngr[21676] DBG: number of certs loaded from store 'ROOT': 73
2022-03-29 08:56:24 dirmngr[21676] DBG: Zertifikat `CA' ist bereits im Zwischenspeicher
2022-03-29 08:56:24 dirmngr[21676] DBG: number of certs loaded from store 'CA': 15
2022-03-29 08:56:24 dirmngr[21676] dauerhaft geladene Zertifikate: 88
2022-03-29 08:56:24 dirmngr[21676] zwischengespeicherte Zertifikate: 0
2022-03-29 08:56:24 dirmngr[21676] vertrauenswÃ¼rdige Zertifikate: 88 (88,0,0,0)
2022-03-29 08:56:25 dirmngr[21676] Handhabungsroutine für fd 732 gestartet
2022-03-29 08:56:25 dirmngr[21676] DBG: chan_0x000002dc -> # Home: C:\Users\#name#\AppData\Roaming\gnupg
2022-03-29 08:56:25 dirmngr[21676] DBG: chan_0x000002dc -> # Config: C:/Users/#name#/AppData/Roaming/gnupg/dirmngr.conf
2022-03-29 08:56:25 dirmngr[21676] DBG: chan_0x000002dc -> OK Dirmngr 2.3.4 at your service
2022-03-29 08:56:25 dirmngr[21676] DBG: chan_0x000002dc <- GETINFO version
2022-03-29 08:56:25 dirmngr[21676] DBG: chan_0x000002dc -> D 2.3.4
2022-03-29 08:56:25 dirmngr[21676] DBG: chan_0x000002dc -> OK
2022-03-29 08:56:25 dirmngr[21676] DBG: chan_0x000002dc <- WKD_GET -- test@sanka-gmbh.de
2022-03-29 08:56:26 dirmngr[21676] DBG: dns: dnsserver[0] '#DNS1#'
2022-03-29 08:56:26 dirmngr[21676] DBG: dns: dnsserver[1] '#DNS2#'
2022-03-29 08:56:26 dirmngr[21676] DBG: dns: libdns initialized
2022-03-29 08:56:26 dirmngr[21676] DBG: dns: resolve_dns_name(openpgpkey.sanka-gmbh.de): Erfolg
2022-03-29 08:56:26 dirmngr[21676] DBG: chan_0x000002dc -> S SOURCE https://openpgpkey.sanka-gmbh.de
2022-03-29 08:56:26 dirmngr[21676] DBG: Using TLS library: NTBTLS 0.2.0
2022-03-29 08:56:26 dirmngr[21676] DBG: check_inet_support: family: 23
2022-03-29 08:56:26 dirmngr[21676] DBG: check_inet_support: addr: #IPv6#
2022-03-29 08:56:26 dirmngr[21676] DBG: check_inet_support: family: 2
2022-03-29 08:56:26 dirmngr[21676] DBG: check_inet_support: addr: #IPv4#
2022-03-29 08:56:26 dirmngr[21676] DBG: http.c:connect_server: trying name='openpgpkey.sanka-gmbh.de' port=443
2022-03-29 08:56:26 dirmngr[21676] DBG: dns: resolve_dns_name(openpgpkey.sanka-gmbh.de): Erfolg
2022-03-29 08:56:26 dirmngr[21676] DBG: http.c:1917:socket_new: object 0x03aa3798 for fd 1080 created
2022-03-29 08:56:26 dirmngr[21676] TLS alert: handshake failure (2.40)
2022-03-29 08:56:26 dirmngr[21676] TLS handshake failed: Fatale "Alert" Nachricht erhalten <TLS>
2022-03-29 08:56:26 dirmngr[21676] Fehler beim Verbinden mit 'https://openpgpkey.sanka-gmbh.de/.well-known/openpgpkey/sanka-gmbh.de/hu/iffe93qcsgp4c8ncbb378rxjo6cn9q6u?l=test': Fatale "Alert" Nachricht erhalten
2022-03-29 08:56:26 dirmngr[21676] command 'WKD_GET' failed: Fatale "Alert" Nachricht erhalten <TLS>
2022-03-29 08:56:26 dirmngr[21676] DBG: chan_0x000002dc -> ERR 285212905 Fatale "Alert" Nachricht erhalten <TLS>
2022-03-29 08:56:26 dirmngr[21676] DBG: chan_0x000002dc <- BYE
2022-03-29 08:56:26 dirmngr[21676] DBG: chan_0x000002dc -> OK closing connection
2022-03-29 08:56:26 dirmngr[21676] Handhabungsroutine für den fd 732 beendet

You can test/replicate it with test@sanka-gmbh.de

Are you using 2.3.4 also on Windows?

I captured some logs server-side, and I do see this error:

http: TLS handshake error from XXX.XXX.XXX.XXX:62625: tls: no cipher suite supported by both client and server

So it's likely still the ciphersuites. I did enable AES-CBC (see report on openpgpkey.sanka-gmbh.de). Specifically, the ciphers are:

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 	256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 	128
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 	256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 	128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 	256

@werner as I understood, either of the AES-CBC are expected to work. did I get that wrong?

In the above test, I was using
Windows: 2.3.4
Debian: 2.2.12

When I install 2.2.12 on Windows, I get the expiered certificate error for the old CN=DST Root CA X3,O=Digital Signature Trust Co. certificate (already fixed).

The ECDHE_ECDSA suites are not yet implemented in ntbtls and thus we can't agree on a common cipher suite. Will be solved in the next Windows version.

Oof. That hinges on the certificate, guess we'll need to renew the bunch of them. I reconfigured, might take a while for all pages but ciphers should now be:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A

Looks good for openpgpkey.sanka-gmbh.de already. Anyone care to test if that works now on Windows?

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

• werner added a commit: rT08c1622944da: Allow ephemeral ECDSA cipher suites..Mar 30 2022, 8:39 PM

Independently of that, it seems that gpg4win doesn't work with at least one widely deployed webserver in its default configuration, specifically Caddy, so this fix is well appreciated.

Thank you, works now on Windows with openpgpkey.sanka-gmbh.de

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Using subdomain in advanced method seems to invite this kind of scheme (as there are dozens of services that operate on the "delegate the subdomain to us and we'll handle the traffic" model, just one random example). That's why I liked the direct method - it was still possible to redirect but it was harder to setup than one DNS record.

I don't like it either but the browser vendors don't like SRV records.

• werner closed this task as Resolved.Apr 20 2022, 8:50 AM

• werner claimed this task.

• werner triaged this task as Normal priority.