TLS handshake frequently hangs for web requests

hotdog_bobby · 2025-10-26 20:20:05

Hello, I'm having trouble diagnosing an issue where web requests will often hang. Sometimes they will resolve after a while, and other times they simply time out. Here's an example of what I mean:

$ time curl -v --trace-time "https://facebook.com"   
15:57:50.343671 * Host facebook.com:443 was resolved.
15:57:50.343728 * IPv6: 2a03:2880:f103:83:face:b00c:0:25de
15:57:50.343759 * IPv4: 31.13.66.35
15:57:50.343806 *   Trying [2a03:2880:f103:83:face:b00c:0:25de]:443...
15:57:50.374171 * ALPN: curl offers h2,http/1.1
15:57:50.374406 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
15:57:50.380089 *  CAfile: /etc/ssl/certs/ca-certificates.crt
15:57:50.380123 *  CApath: none
15:58:20.119405 * TLSv1.3 (IN), TLS handshake, Server hello (2):
15:58:20.119873 * TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
15:58:20.159362 * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
15:58:20.159439 * TLSv1.3 (IN), TLS handshake, Certificate (11):
15:58:20.159965 * TLSv1.3 (IN), TLS handshake, CERT verify (15):
15:58:20.160214 * TLSv1.3 (IN), TLS handshake, Finished (20):
15:58:20.160314 * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
15:58:20.160393 * TLSv1.3 (OUT), TLS handshake, Finished (20):
15:58:20.160486 * SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256 / X25519MLKEM768 / id-ecPublicKey
15:58:20.160537 * ALPN: server accepted h2
15:58:20.160583 * Server certificate:
15:58:20.160643 *  subject: C=US; ST=California; L=Menlo Park; O="Meta Platforms, Inc."; CN=*.facebook.com
15:58:20.160692 *  start date: Aug  5 00:00:00 2025 GMT
15:58:20.160742 *  expire date: Nov  3 23:59:59 2025 GMT
15:58:20.160799 *  subjectAltName: host "facebook.com" matched cert's "facebook.com"
15:58:20.160855 *  issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
15:58:20.160902 *  SSL certificate verify ok.
15:58:20.160947 *   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
15:58:20.160988 *   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
15:58:20.161028 *   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
15:58:20.161101 * Established connection to facebook.com (2a03:2880:f103:83:face:b00c:0:25de port 443) from (...) port 59622 
15:58:20.161160 * using HTTP/2
15:58:20.161222 * [HTTP/2] [1] OPENED stream for https://facebook.com/
15:58:20.161270 * [HTTP/2] [1] [:method: GET]
15:58:20.161317 * [HTTP/2] [1] [:scheme: https]
15:58:20.161365 * [HTTP/2] [1] [:authority: facebook.com]
15:58:20.161411 * [HTTP/2] [1] [:path: /]
15:58:20.161454 * [HTTP/2] [1] [user-agent: curl/8.16.0]
15:58:20.161496 * [HTTP/2] [1] [accept: */*]
15:58:20.161559 > GET / HTTP/2
15:58:20.161559 > Host: facebook.com
15:58:20.161559 > User-Agent: curl/8.16.0
15:58:20.161559 > Accept: */*
15:58:20.161559 > 
15:58:20.161806 * Request completely sent off
15:58:20.194482 * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
15:58:20.231519 < HTTP/2 301 
15:58:20.231583 < location: https://www.facebook.com/
15:58:20.231640 < strict-transport-security: max-age=15552000; preload
15:58:20.231690 < content-type: text/html; charset="utf-8"
15:58:20.231746 < x-fb-debug: RJK7EuJwWIhR9qPc9qkicYutETyexI9cQTaiXBfQtDv3rexcND+9g0Ob2dliiTCrpjmmzqJ6ejhKAUD8Zw+cNA==
15:58:20.231794 < content-length: 0
15:58:20.231845 < date: Sun, 26 Oct 2025 19:58:20 GMT
15:58:20.231894 < x-fb-connection-quality: EXCELLENT; q=0.9, rtt=31, rtx=11, c=7, mss=1380, tbw=4674, tp=-1, tpl=-1, uplat=36, ullat=0
15:58:20.231945 < alt-svc: h3=":443"; ma=86400
15:58:20.231997 < 
15:58:20.232067 * Connection #0 to host facebook.com:443 left intact
curl -v --trace-time "https://facebook.com"  0.01s user 0.01s system 0% cpu 29.927 total

As you might notice, DNS resolution occurs quickly, but it took about 30 seconds to get the "hello" back from the server. In this example I've tried to hit Facebook, but this happens intermittently as I am doing my usual web browsing. It does not seem to happen on Windows if I boot into it on this same machine, so I think there is some system-level misconfiguration on my Arch install, but I don't know where to go from here.

hotdog_bobby · 2025-10-26 22:52:29

Here's another example, trying to curl the Arch Linux forums, where the handshake hangs at a slightly later point:

time curl -v --trace-time "https://bbs.archlinux.org"
18:45:23.365709 * Host bbs.archlinux.org:443 was resolved.
18:45:23.365776 * IPv6: 2a01:4f8:c2c:b1cf::1
18:45:23.365805 * IPv4: 116.203.93.142
18:45:23.365848 *   Trying [2a01:4f8:c2c:b1cf::1]:443...
18:45:23.507585 * ALPN: curl offers h2,http/1.1
18:45:23.507814 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
18:45:23.513835 *  CAfile: /etc/ssl/certs/ca-certificates.crt
18:45:23.513862 *  CApath: none
18:45:23.654998 * TLSv1.3 (IN), TLS handshake, Server hello (2):
18:45:23.655545 * TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
18:45:23.655601 * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
18:46:18.256437 * TLSv1.3 (IN), TLS handshake, Certificate (11):
18:46:18.258154 * TLSv1.3 (IN), TLS handshake, CERT verify (15):
18:46:18.258371 * TLSv1.3 (IN), TLS handshake, Finished (20):
18:46:18.258466 * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
18:46:18.258545 * TLSv1.3 (OUT), TLS handshake, Finished (20):
18:46:18.258637 * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
18:46:18.258687 * ALPN: server accepted h2
18:46:18.258732 * Server certificate:
18:46:18.258781 *  subject: CN=bbs.archlinux.org
18:46:18.258826 *  start date: Sep 17 13:14:10 2025 GMT
18:46:18.258871 *  expire date: Dec 16 13:14:09 2025 GMT
18:46:18.258919 *  subjectAltName: host "bbs.archlinux.org" matched cert's "bbs.archlinux.org"
18:46:18.258967 *  issuer: C=US; O=Let's Encrypt; CN=E7
18:46:18.259010 *  SSL certificate verify ok.
18:46:18.259058 *   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
18:46:18.259104 *   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
18:46:18.259159 *   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
18:46:18.259231 * Established connection to bbs.archlinux.org (2a01:4f8:c2c:b1cf::1 port 443) from (...) port 42746 
18:46:18.259279 * using HTTP/2
18:46:18.259342 * [HTTP/2] [1] OPENED stream for https://bbs.archlinux.org/
18:46:18.259386 * [HTTP/2] [1] [:method: GET]
18:46:18.259430 * [HTTP/2] [1] [:scheme: https]
18:46:18.259474 * [HTTP/2] [1] [:authority: bbs.archlinux.org]
18:46:18.259517 * [HTTP/2] [1] [:path: /]
18:46:18.259561 * [HTTP/2] [1] [user-agent: curl/8.16.0]
18:46:18.259606 * [HTTP/2] [1] [accept: */*]
18:46:18.259673 > GET / HTTP/2
18:46:18.259673 > Host: bbs.archlinux.org
18:46:18.259673 > User-Agent: curl/8.16.0
18:46:18.259673 > Accept: */*
18:46:18.259673 > 
18:46:18.259928 * Request completely sent off
18:46:18.404197 * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
18:46:18.404312 * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
18:46:18.817882 < HTTP/2 200 
18:46:18.817938 < server: nginx
18:46:18.817985 < date: Sun, 26 Oct 2025 22:46:18 GMT
18:46:18.818029 < content-type: text/html; charset=utf-8
18:46:18.818071 < expires: Thu, 21 Jul 1977 07:30:00 GMT
18:46:18.818129 < last-modified: Sun, 26 Oct 2025 22:46:18 GMT
18:46:18.818179 < cache-control: post-check=0, pre-check=0
18:46:18.818226 < pragma: no-cache
18:46:18.818275 < x-frame-options: deny
18:46:18.818327 < strict-transport-security: max-age=31536000; includeSubdomains; preload
18:46:18.818374 < (content)

seth · 2025-10-26 23:27:19

Leaving aside

It does not seem to happen on Windows if I boot into it on this same machine

https://bbs.archlinux.org/viewtopic.php … 2#p2269662
https://bbs.archlinux.org/viewtopic.php … 0#p2269680

Since when is this the case and can you reach the AUR at all or does the handshake also break down?

Because of the dual boot, see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Though this doesn't look like a related outcome of that condition and if we assume the other situations to be coincidental, I'd look at the MTU (and try to lower it to 1280 or so)

hotdog_bobby · 2025-10-28 02:39:03

seth wrote:

Leaving aside
It does not seem to happen on Windows if I boot into it on this same machine
https://bbs.archlinux.org/viewtopic.php … 2#p2269662
https://bbs.archlinux.org/viewtopic.php … 0#p2269680
Since when is this the case and can you reach the AUR at all or does the handshake also break down?
Because of the dual boot, see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Though this doesn't look like a related outcome of that condition and if we assume the other situations to be coincidental, I'd look at the MTU (and try to lower it to 1280 or so)

I can hit the AUR. I also do not have fast boot enabled.

Worth noting that this box is connected over MoCA - I haven't discounted the possibility that it's a network issue, but I find it odd that requests are consistently getting hung up at the TLS setup.

ahepp · 2025-10-28 03:21:21

Are you sure the DNS entries aren't just cached on your host or on your router? A Wireshark capture might give you some interesting insights if there is some weird TCP stuff going on.

seth · 2025-10-28 07:45:33

The OP has no problems reaching the servers, the TLS handshake just stalls for up to a minute.

Worth noting that this box is connected over MoCA

I couldn't find anything about the standard adding extra package overhead - lowering the MTU might still be worth a shot (there two bigger packages involved and you seem to stall at either of them)
Is it only the TLS handshake? Other traffic has constant throughput?
Is your system time properly synced?

seth wrote:

Since when is this the case

Arch Linux

#1 2025-10-26 20:20:05

TLS handshake frequently hangs for web requests

#2 2025-10-26 22:52:29

Re: TLS handshake frequently hangs for web requests

#3 2025-10-26 23:27:19

Re: TLS handshake frequently hangs for web requests

#4 2025-10-28 02:39:03

Re: TLS handshake frequently hangs for web requests

#5 2025-10-28 03:21:21

Re: TLS handshake frequently hangs for web requests

#6 2025-10-28 07:45:33

Re: TLS handshake frequently hangs for web requests

Board footer