dirmngr: Fix proxy with TLS.
Concern Raised04cbc3074aa9
Actions

Description

dirmngr: Fix proxy with TLS.

* dirmngr/http.c (proxy_get_token, run_proxy_connect): Always
available regardless of USE_TLS.
(run_proxy_connect): Use log_debug_string.
(send_request): Remove USE_TLS.

Since the commit of

1009e4e5f71347a1fe194e59a9d88c8034a67016

Building with TLS library is mandatory.

GnuPG-bug-id: T6997
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>

Details

Auditors

hlein

Provenance

• gniibe

Authored on Feb 15 2024, 7:38 AM

Parents

rG302afcb6f6af: gpg: Add option --assert-pubkey_algo.

Branches

Unknown

Tags

Unknown

Tasks

T6997: gnupg-2.4.4 breaks dirmngr fetching keys via hkps:// from behind a proxy

Event Timeline

• gniibe committed rG04cbc3074aa9: dirmngr: Fix proxy with TLS. (authored by • gniibe).Feb 15 2024, 7:38 AM

• gniibe added a task: T6997: gnupg-2.4.4 breaks dirmngr fetching keys via hkps:// from behind a proxy.Feb 15 2024, 7:42 AM

• gniibe mentioned this in T6997: gnupg-2.4.4 breaks dirmngr fetching keys via hkps:// from behind a proxy.Feb 15 2024, 7:44 AM

Thank you for the quick attention!

I'm not sure if this was intended to be a complete fix. This has changed behavior but it's still not right.

Now the proxy does see a CONNECT... request, but then after that... nothing.

I enabled debugging in dirmngr.conf with:

debug-level guru
debug-all
tls-debug 9

With 2.4.4+patch, doing gpg --keyserver hkps://keys.gentoo.org --recv-keys 39EA32FE8222EEEC I see some stuff that ends with:

...
2024-02-15 15:33:40 dirmngr[1985.6] DBG: http.c:proxy:request:
2024-02-15 15:33:40 dirmngr[1985.6] DBG: >> CONNECT keys.gentoo.org:443 HTTP/1.1\r\n
2024-02-15 15:33:40 dirmngr[1985.6] DBG: >> Host: keys.gentoo.org:443\r\n
2024-02-15 15:33:40 dirmngr[1985.6] DBG: >> Connection: keep-alive\r\n
2024-02-15 15:33:40 dirmngr[1985.6] DBG: http.c:request-header:start_data:
2024-02-15 15:33:40 dirmngr[1985.6] DBG: network read: 39/8192
2024-02-15 15:33:40 dirmngr[1985.6] DBG: http.c:response:
2024-02-15 15:33:40 dirmngr[1985.6] DBG: >> HTTP/1.1 200 Connection established\r\n
2024-02-15 15:33:40 dirmngr[1985.6] http.c:RESP: ''

And there it sits for 5 minutes until:

2024-02-15 15:38:40 dirmngr[1985.6] DBG: network read: 0/8192
2024-02-15 15:38:40 dirmngr[1985.6] DBG: http.c:proxy_connect: skipped 0 bytes of response-bo
dy
2024-02-15 15:38:40 dirmngr[1985.6] DBG: gnutls:L5: REC[0x7fd61000d560]: Allocating epoch #1
2024-02-15 15:38:40 dirmngr[1985.6] DBG: gnutls:L4: HSK[0x7fd61000d560]: Adv. version: 3.3
2024-02-15 15:38:40 dirmngr[1985.6] DBG: gnutls:L2: Keeping ciphersuite 13.02 (GNUTLS_AES_256_GCM_SHA384)
...
2024-02-15 15:38:40 dirmngr[1985.6] TLS handshake failed: The TLS connection was non-properly terminated.
2024-02-15 15:38:40 dirmngr[1985.6] error connecting to 'https://keys.gentoo.org:443': Network error
2024-02-15 15:38:40 dirmngr[1985.6] DBG: gnutls:L5: REC[0x7fd61000d560]: Start of epoch cleanup
2024-02-15 15:38:40 dirmngr[1985.6] DBG: gnutls:L5: REC[0x7fd61000d560]: End of epoch cleanup
2024-02-15 15:38:40 dirmngr[1985.6] DBG: gnutls:L5: REC[0x7fd61000d560]: Epoch #0 freed
2024-02-15 15:38:40 dirmngr[1985.6] DBG: gnutls:L5: REC[0x7fd61000d560]: Epoch #1 freed
2024-02-15 15:38:40 dirmngr[1985.6] marking host 'keys.gentoo.org' as dead
2024-02-15 15:38:40 dirmngr[1985.6] host 'keys.gentoo.org' marked as dead
2024-02-15 15:38:40 dirmngr[1985.6] command 'KS_GET' failed: No keyserver available
2024-02-15 15:38:40 dirmngr[1985.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2024-02-15 15:38:40 dirmngr[1985.6] DBG: chan_6 <- BYE
2024-02-15 15:38:40 dirmngr[1985.6] DBG: chan_6 -> OK closing connection
2024-02-15 15:38:40 dirmngr[1985.6] handler for fd 6 terminated

By contrast, 2.4.3 which works behind the same proxy, same debug level enabled, same request:

...
2024-02-15 15:35:11 dirmngr[16169.6] DBG: http.c:request:
2024-02-15 15:35:11 dirmngr[16169.6] DBG: >> CONNECT keys.gentoo.org:443 HTTP/1.0\r\n
2024-02-15 15:35:11 dirmngr[16169.6] DBG: >> Host: keys.gentoo.org:443\r\n
2024-02-15 15:35:11 dirmngr[16169.6] DBG: http.c:request-header:
2024-02-15 15:35:11 dirmngr[16169.6] DBG: >> \r\n
2024-02-15 15:35:11 dirmngr[16169.6] DBG: http.c:response:
2024-02-15 15:35:11 dirmngr[16169.6] DBG: >> HTTP/1.1 200 Connection established\r\n
2024-02-15 15:35:11 dirmngr[16169.6] http.c:RESP: ''
2024-02-15 15:35:11 dirmngr[16169.6] DBG: gnutls:L5: REC[0x7f496000c060]: Allocating epoch #1
2024-02-15 15:35:11 dirmngr[16169.6] DBG: gnutls:L4: HSK[0x7f496000c060]: Adv. version: 3.3
2024-02-15 15:35:11 dirmngr[16169.6] DBG: gnutls:L2: Keeping ciphersuite 13.02 (GNUTLS_AES_256_GCM_SHA384)
...
2024-02-15 15:35:11 dirmngr[16169.6] DBG: gnutls:L4: HSK[0x7f496000c060]: SERVER HELLO (2) was received. Length 151[151], frag offset 0, frag length: 151, sequence: 0
...
2024-02-15 15:35:11 dirmngr[16169.6] DBG: http.c:request:
2024-02-15 15:35:11 dirmngr[16169.6] DBG: >> GET /pks/lookup?op=get&options=mr&search=0x39EA32FE8222EEEC HTTP/1.0\r\n
2024-02-15 15:35:11 dirmngr[16169.6] DBG: >> Host: keys.gentoo.org\r\n
...
2024-02-15 15:35:12 dirmngr[16169.6] DBG: http.c:response:
2024-02-15 15:35:12 dirmngr[16169.6] DBG: >> HTTP/1.1 200 OK\r\n
2024-02-15 15:35:12 dirmngr[16169.6] http.c:RESP: 'Date: Thu, 15 Feb 2024 20:35:12 GMT'
2024-02-15 15:35:12 dirmngr[16169.6] http.c:RESP: 'Server: sks_www/1.1.6+'
...
2024-02-15 15:35:12 dirmngr[16169.6] DBG: chan_6 -> OK
2024-02-15 15:35:12 dirmngr[16169.6] DBG: chan_6 <- BYE
2024-02-15 15:35:12 dirmngr[16169.6] DBG: chan_6 -> OK closing connection
2024-02-15 15:35:12 dirmngr[16169.6] handler for fd 6 terminated

So no delay after HTTP/1.1 200 Connection established, TLS negotiated, request sent, answer received.

This commit now has outstanding concerns.Feb 15 2024, 9:47 PM

thesamesam added a subscriber: thesamesam.Feb 15 2024, 10:43 PM