Chrome 143, Post-Quantum Crypto, and Port 2083

by Gary Illyes

You updated Chrome. Now your cPanel URL (:2083) spins until it times out. You blame the Wi-Fi. You blame DNS. You blame the registrar.

It’s none of those things. It’s the future, and the future is stupidly large.

The Symptom

GoDaddy cPanel links, those https://p3plzcpnl489516.prod.phx3.secureserver.net:2083/cpsess... fail in Chrome (143 for me). They work in Firefox. They work in Edge. They work if you proxy through port 443. But if you try to hit port 2083 directly, the browser hangs at the handshake.

But Why, Pray Do Tell

Just like any normal human would do, I captured a chrome://net-export log. DNS resolves fine. TCP connects fine. The browser sends the SSL ClientHello… and that's it. The server just blinks at the packet without reacting.

Digging further, it appears that Chrome forces Post-Quantum Cryptography (specifically the Kyber/ML-KEM algorithm) and Encrypted ClientHello (ECH) by default, perhaps since around September 2025.

The intention is to prevent quantum computers from decrypting my traffic ten years from now. The reality is that it bloats the initial handshake packet size significantly. The firewall on the hosting server (likely CSF or LFD) sees this unusually fat packet hitting a non-standard port, flags it as a buffer overflow attempt (maybe?), and silently drops it. Or at least that's what I think is happening.

It is a security feature protecting you from a server that is protecting itself from you.

The Fix

Just turn it off!

Shush now; you can't "just turn it off", believe me, I tried. The fix is not in chrome://flags anymore. You have to force Chrome to be dumber via the Registry. Yes, capital "R".

My fix was to edit Chrome's policies in the Windows registry. Set every new stuff that might change the ClientHello size to false, because what can go wrong. If you want to try it, save this as fix_chrome.reg and run it: 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EncryptedClientHelloEnabled"=dword:00000000
"PostQuantumKeyAgreementEnabled"=dword:00000000

Verification

Restart Chrome and visit the Cloudflare trace tool at https://cloudflare.com/cdn-cgi/trace.

Look at the kex line.

Summary

The hosting provider needs to update their firewall rules to accept larger ClientHello packets. Until they do, you have to downgrade your browser’s cryptography standards. Security is a trade-off, usually between "safe" and "functional."