MagicBeanDev/LongshotLauncher

Watch

Fork 24

Windows: Update checks fail TLS handshake for Git hosts (SNI-dependent) #120

New issue

Open

opened 2026-11-15 22:25:14 +00:00 by HappySpleen · 3 comments

HappySpleen commented

2026-11-15 22:25:14 +00:00

What happened

Longshot Launcher update checks stopped working on November 15, 2026, despite previously working with v1.0.0-rc.3.

The issue began while still running RC3. After manually updating to v1.0.0-rc.7 and then nightly-90-b1fd0550, the update check continued failing, but the newer launcher provided more detailed diagnostics.

Both git-cdn.magicbean.dev and git.magicbean.dev resolve correctly and accept TCP connections on port 443, but the TLS handshake fails before any HTTP response is received.

Launcher error:

SecureConnectionError
AuthenticationException:
Cannot determine the frame size or a corrupted frame was received.

This prevents the launcher from determining available Longshot and launcher updates.

Steps to reproduce

Run Longshot Launcher on the affected Windows 10 system.
Allow the automatic update check or manually check for updates.
The launcher attempts git-cdn.magicbean.dev, then falls back to git.magicbean.dev.
Both attempts fail during TLS negotiation.
Update availability cannot be determined.

Frequency: Consistently reproducible since November 15, 2026.

Expected behavior

The launcher successfully establishes an HTTPS connection, retrieves the release metadata, and determines whether updates are available.

Actual behavior

DNS resolution and TCP connectivity succeed, but TLS negotiation fails for both Git hostnames.

Environment

OS: Windows 10 22H2 (build 19045), x64
Launcher: v1.0.0-rc.7, nightly-90-b1fd0550 (installed)
Previously working: v1.0.0-rc.3
.NET runtime: 10.0.15
Launcher channel: rc
Build channel: rc
Proxy: None reported by launcher
Windows curl: 8.13.0 (Schannel)
Git for Windows curl: 8.19.0 (Schannel)
OpenSSL: 3.5.6

Network and TLS diagnostics

1. DNS and connectivity

Both Git hostnames resolve successfully.
TCP connections on port 443 succeed.
Both IPv4 and IPv6 exhibit the same TLS failure.
Forcing TLS 1.2 does not resolve the issue.
Disabling ALPN does not resolve the issue.
HTTPS requests to GitHub, Cloudflare, and magicbean.dev succeed using Windows Schannel.

2. Hostname-specific failure

Using curl's --resolve option to test different hostnames against the same Cloudflare IP addresses:

Hostname	IP address	Result
git.magicbean.dev	104.21.55.71	TLS failure
git.magicbean.dev	172.67.170.160	TLS failure
magicbean.dev	104.21.55.71	HTTP 200
magicbean.dev	172.67.170.160	HTTP 200

The failure follows the hostname rather than the IP address.

3. OpenSSL handshake inspection

An OpenSSL TLS 1.2 handshake to 104.21.55.71:443, using SNI git.magicbean.dev, receives invalid response data immediately after ClientHello:

read from ... (5 bytes)
0000 - ff ff ff ff ff

read from ... (251 bytes)
0000 - ff ff ff ff ff ff ff ff ...

The response consists of 256 consecutive 0xFF bytes instead of valid TLS records.

OpenSSL reports:

tls_validate_record_header:wrong version number

Changing only the SNI hostname to magicbean.dev, while retaining the same IP address and TLS version, successfully negotiates TLS 1.2 and verifies the certificate.

This suggests hostname-dependent handling of the TLS ClientHello.

4. Firefox ECH testing

Firefox can successfully retrieve the release API JSON.

Testing Firefox with HTTP/3 disabled:

Configuration	Result
ECH enabled	HTTPS succeeds; JSON returned
ECH disabled	Connection fails

The failure therefore appears dependent on ECH-related TLS behavior. This could indicate hostname-based traffic inspection/filtering or a difference in how the endpoint handles ClientHello messages.

5. External TLS compatibility

SSL Labs successfully assessed all four Cloudflare endpoints and confirmed:

TLS 1.2 is supported.
TLS 1.3 is supported.
Simulated Windows 10 clients can successfully negotiate TLS 1.2.

This suggests the issue is not simply the absence of Windows 10-compatible protocols or cipher suites.

Additional context

The issue appeared in RC3 before any manual launcher update.
Manually upgrading to RC7 and then nightly 90 did not restore connectivity.
The problem is reproducible independently using Schannel and OpenSSL.
The underlying release API works when accessed successfully through Firefox.
Testing from a different network was not possible.

The RC5 release notes also mention updates to connection error reporting (#75) and using the CDN first for release metadata (#76). These changes appear related to Git service availability, although it is not established whether they address the same underlying problem.

Possible areas to investigate

The available evidence suggests investigating:

Cloudflare WAF, security, or TLS settings associated with the Git hostnames.
Whether hostname/SNI-based traffic filtering is occurring along the connection path.
Differences in TLS ClientHello handling between ECH and non-ECH clients.
Any relevant infrastructure or security configuration changes around November 14–15, 2026.

The source of the invalid TLS response has not been identified. It could originate from an intermediary or from endpoint-side handling.

It would be useful to confirm whether the Cloudflare edge receives the failed ClientHello and whether similar reports exist from other Windows clients.

Impact

The launcher cannot check for game or launcher updates, even though the releases are accessible through Firefox.

A manual launcher update does not resolve the underlying connectivity failure.

## What happened Longshot Launcher update checks stopped working on November 15, 2026, despite previously working with **v1.0.0-rc.3**. The issue began while still running RC3. After manually updating to **v1.0.0-rc.7** and then **nightly-90-b1fd0550**, the update check continued failing, but the newer launcher provided more detailed diagnostics. Both `git-cdn.magicbean.dev` and `git.magicbean.dev` resolve correctly and accept TCP connections on port 443, but the TLS handshake fails before any HTTP response is received. **Launcher error:** ``` SecureConnectionError AuthenticationException: Cannot determine the frame size or a corrupted frame was received. ``` This prevents the launcher from determining available Longshot and launcher updates. ## Steps to reproduce 1. Run Longshot Launcher on the affected Windows 10 system. 2. Allow the automatic update check or manually check for updates. 3. The launcher attempts `git-cdn.magicbean.dev`, then falls back to `git.magicbean.dev`. 4. Both attempts fail during TLS negotiation. 5. Update availability cannot be determined. **Frequency:** Consistently reproducible since November 15, 2026. ## Expected behavior The launcher successfully establishes an HTTPS connection, retrieves the release metadata, and determines whether updates are available. ## Actual behavior DNS resolution and TCP connectivity succeed, but TLS negotiation fails for both Git hostnames. ## Environment - **OS:** Windows 10 22H2 (build 19045), x64 - **Launcher:** v1.0.0-rc.7, nightly-90-b1fd0550 (installed) - **Previously working:** v1.0.0-rc.3 - **.NET runtime:** 10.0.15 - **Launcher channel:** rc - **Build channel:** rc - **Proxy:** None reported by launcher - **Windows curl:** 8.13.0 (Schannel) - **Git for Windows curl:** 8.19.0 (Schannel) - **OpenSSL:** 3.5.6 ## Network and TLS diagnostics ### 1. DNS and connectivity - Both Git hostnames resolve successfully. - TCP connections on port 443 succeed. - Both IPv4 and IPv6 exhibit the same TLS failure. - Forcing TLS 1.2 does not resolve the issue. - Disabling ALPN does not resolve the issue. - HTTPS requests to GitHub, Cloudflare, and `magicbean.dev` succeed using Windows Schannel. ### 2. Hostname-specific failure Using curl's `--resolve` option to test different hostnames against the same Cloudflare IP addresses: | Hostname | IP address | Result | |---|---|---| | git.magicbean.dev | 104.21.55.71 | TLS failure | | git.magicbean.dev | 172.67.170.160 | TLS failure | | magicbean.dev | 104.21.55.71 | HTTP 200 | | magicbean.dev | 172.67.170.160 | HTTP 200 | The failure follows the hostname rather than the IP address. ### 3. OpenSSL handshake inspection An OpenSSL TLS 1.2 handshake to `104.21.55.71:443`, using SNI `git.magicbean.dev`, receives invalid response data immediately after ClientHello: ``` read from ... (5 bytes) 0000 - ff ff ff ff ff read from ... (251 bytes) 0000 - ff ff ff ff ff ff ff ff ... ``` The response consists of 256 consecutive `0xFF` bytes instead of valid TLS records. OpenSSL reports: ``` tls_validate_record_header:wrong version number ``` Changing only the SNI hostname to `magicbean.dev`, while retaining the same IP address and TLS version, successfully negotiates TLS 1.2 and verifies the certificate. This suggests hostname-dependent handling of the TLS ClientHello. ### 4. Firefox ECH testing Firefox can successfully retrieve the release API JSON. Testing Firefox with HTTP/3 disabled: | Configuration | Result | |---|---| | ECH enabled | HTTPS succeeds; JSON returned | | ECH disabled | Connection fails | The failure therefore appears dependent on ECH-related TLS behavior. This could indicate hostname-based traffic inspection/filtering or a difference in how the endpoint handles ClientHello messages. ### 5. External TLS compatibility SSL Labs successfully assessed all four Cloudflare endpoints and confirmed: - TLS 1.2 is supported. - TLS 1.3 is supported. - Simulated Windows 10 clients can successfully negotiate TLS 1.2. This suggests the issue is not simply the absence of Windows 10-compatible protocols or cipher suites. ## Additional context - The issue appeared in RC3 before any manual launcher update. - Manually upgrading to RC7 and then nightly 90 did not restore connectivity. - The problem is reproducible independently using Schannel and OpenSSL. - The underlying release API works when accessed successfully through Firefox. - Testing from a different network was not possible. The RC5 release notes also mention updates to connection error reporting (#75) and using the CDN first for release metadata (#76). These changes appear related to Git service availability, although it is not established whether they address the same underlying problem. ## Possible areas to investigate The available evidence suggests investigating: - Cloudflare WAF, security, or TLS settings associated with the Git hostnames. - Whether hostname/SNI-based traffic filtering is occurring along the connection path. - Differences in TLS ClientHello handling between ECH and non-ECH clients. - Any relevant infrastructure or security configuration changes around November 14–15, 2026. **The source of the invalid TLS response has not been identified.** It could originate from an intermediary or from endpoint-side handling. It would be useful to confirm whether the Cloudflare edge receives the failed ClientHello and whether similar reports exist from other Windows clients. ## Impact The launcher cannot check for game or launcher updates, even though the releases are accessible through Firefox. A manual launcher update does not resolve the underlying connectivity failure.

01_Longshot_Launcher_Log.txt

9.2 KiB

02_OpenSSL_Test1_Git_Hostname_Failure.txt

3.4 KiB

03_OpenSSL_Test2_Main_Hostname_Success.txt

22 KiB

👀 1

BeanIssues added the

labels

2026-11-15 22:25:31 +00:00

BeanIssues commented

2026-11-15 22:25:31 +00:00

Collaborator

Possibly related, for context:

MagicBeanDev/Longshot#738 Install: Launcher cannot determine build version when git.magicbean.dev does not respond — Related failure reaching the same Git host from the launcher; its report also includes a TLS update-check error, though the cause and level of detail differ.

Possibly related, for context: - MagicBeanDev/Longshot#738 Install: Launcher cannot determine build version when git.magicbean.dev does not respond — Related failure reaching the same Git host from the launcher; its report also includes a TLS update-check error, though the cause and level of detail differ.

potato commented

2026-11-15 22:36:58 +00:00

The nightly log shows DNS resolution and IPv6 TCP connections succeeding for both hosts. The release API on git.magicbean.dev returns HTTP 200 after the CDN request fails. The launcher then hits SecureConnectionError / AuthenticationException ("Cannot determine the frame size or a corrupted frame was received") fetching SHA256SUMS from the CDN. The fallback download through git.magicbean.dev also fails after connecting to the CDN.

Opera GX on the same PC successfully downloads the exact file that fails in the launcher: https://git-cdn.magicbean.dev/MagicBeanDev/Longshot/releases/download/v3.0.0-rc.4/SHA256SUMS

I hit the same TLS error on a first build. The Build button stays disabled in v1.0.0-rc.7 and in the portable nightly-91-d79e1e4f. I tried both my usual connection and a phone hotspot, with the same result. The nightly reports Windows build 26300 (x64), .NET 10.0.15, and no proxy. The nightly log shows DNS resolution and IPv6 TCP connections succeeding for both hosts. The release API on `git.magicbean.dev` returns HTTP 200 after the CDN request fails. The launcher then hits `SecureConnectionError` / `AuthenticationException` ("Cannot determine the frame size or a corrupted frame was received") fetching `SHA256SUMS` from the CDN. The fallback download through `git.magicbean.dev` also fails after connecting to the CDN. Opera GX on the same PC successfully downloads the exact file that fails in the launcher: https://git-cdn.magicbean.dev/MagicBeanDev/Longshot/releases/download/v3.0.0-rc.4/SHA256SUMS

BeanIssues commented

2026-11-15 22:45:05 +00:00

Collaborator

From Shadow on Discord:

A further report from Longshot Launcher v1.0.0-rc.6: the Build screen says “git.magicbean.dev did not answer, so the version to build is not known. Try again” and reports “The secure connection to git.magicbean.dev failed… (Cannot determine the frame size or a corrupted frame was received)”. The Build button is disabled. No OS, network details, or launcher log supplied.

From [Shadow on Discord](https://discord.com/channels/1569849200047427645/1570784344241340417/1571639923176382496): A further report from Longshot Launcher v1.0.0-rc.6: the Build screen says “git.magicbean.dev did not answer, so the version to build is not known. Try again” and reports “The secure connection to git.magicbean.dev failed… (Cannot determine the frame size or a corrupted frame was received)”. The Build button is disabled. No OS, network details, or launcher log supplied.