Firefox SSL_ERROR_RX_RECORD_TOO_LONG Fix (Antivirus)

Firefox throws SSL_ERROR_RX_RECORD_TOO_LONG when antivirus HTTPS scanning mangles the TLS handshake. Here's how to fix it without disabling your protection entirely.

You open Firefox, type in your bank's URL or your company's OWA, and instead of a login page you get Secure Connection Failed with SSL_ERROR_RX_RECORD_TOO_LONG. Sometimes it hits every HTTPS site, sometimes just one. It usually starts right after an antivirus update, a fresh install of Kaspersky, Bitdefender, ESET, Avast, or AVG, or after IT pushed a new web-filtering policy. Chrome opens the same site fine. Edge too. Firefox is the only one complaining.

What's actually going wrong

The name of this error is misleading. Firefox isn't receiving a record that's "too long" in any meaningful sense — it's receiving something that isn't a TLS record at all, and the first two bytes of that something happen to decode as a length value that makes no sense, so Firefox bails out before parsing further.

Here's the sequence. Firefox opens a TCP connection to example.com:443 and sends a TLS ClientHello. It expects the server to reply with a TLS ServerHello. What it gets back instead is a plain HTTP response — usually a 302 or a chunk of HTML from your antivirus's local proxy. That HTML starts with bytes like 48 54 54 50 ("HTTP"). Firefox looks at those first two bytes, sees 0x4854, interprets that as a TLS record length of ~18,516 bytes, and throws SSL_ERROR_RX_RECORD_TOO_LONG. The record it thinks it's about to read is impossibly large for the actual connection.

The culprit here is almost always antivirus HTTPS/SSL scanning. Products like Kaspersky, Bitdefender, ESET, Avast, AVG, Norton, and Comodo install a local root CA and intercept every TLS session so they can scan decrypted traffic. They hand Firefox a certificate signed by their own CA. If Firefox doesn't trust that CA — because it uses its own certificate store on some builds, or the CA got removed, or the AV's Firefox integration broke — the handshake falls apart and you end up with garbage that looks like an oversized TLS record.

Corporate web filters do this too. Zscaler, Netskope, Forcepoint, and Palo Alto all do TLS inspection. Same failure mode, same error code.

The fix, in order

Confirm it's the AV. Open Firefox in Safe Mode first: firefox.exe -safe-mode from a command prompt. If the site loads, the problem is an extension or a profile setting. If it still fails, keep going — it's the AV or a proxy. Also try curl -v https://example.com from PowerShell. If curl sees the same broken response, the problem is below Firefox.
Check what certificate Firefox is actually seeing. Click the padlock (or the crossed-out padlock), then Connection not secure → More information → View Certificate. If the issuer is your antivirus (e.g. "Kaspersky Anti-Virus Personal Root Certificate"), that confirms interception. If the issuer is something random like "Fortinet" or "Zscaler", it's a corporate filter.
Make Firefox trust the AV's root CA. In Firefox, go to Settings → Privacy & Security → scroll to Certificates → View Certificates → Authorities tab. Look for your AV vendor's root. If it's there, select it, click Edit Trust, and tick "This certificate can identify websites." That single checkbox fixes this for a lot of people. If the AV root isn't listed, export it from the Windows cert store (certmgr.msc → Trusted Root Certification Authorities) as a Base-64 .cer file, then import it in the same Firefox dialog via Import.
Re-run the AV's Firefox integration. Most vendors ship a repair option that re-installs their cert into all browsers. Kaspersky: Settings → Additional → Network → Encrypted connection scanning → click Install certificate again. Bitdefender: Protection → Online Threat Prevention → Encrypted web scan → toggle off, reboot, toggle back on. This forces a fresh cert install and rewrites the proxy config.
If you don't need HTTPS scanning, turn it off. The real fix for a home user is usually to disable HTTPS scanning entirely. It's a strong MITM by design, it slows page loads, and modern browsers already block most of what the AV is looking for. Kaspersky: uncheck Encrypted connection scanning. Avast/AVG: Protection → Core Shields → Web Shield → Settings → uncheck Enable HTTPS scanning. ESET: Setup → Internet protection → SSL/TLS → disable SSL/TLS filtering. Norton: Settings → Firewall → Intrusion Prevention, and turn off HTTPS inspection. On a corporate machine, don't do this — talk to IT.
Check for a proxy or PAC file. Firefox has its own proxy settings that don't always follow Windows. Go to Settings → Network Settings. If it's set to Use system proxy settings, check Windows too (inetcpl.cpl → Connections → LAN settings). A stale PAC file pointing at a decommissioned proxy produces exactly this error.
Flush stale TLS state. Close Firefox, then delete cert9.db, key4.db, and pkcs11.txt from your profile folder (back them up first — this wipes saved cert exceptions). Profile path on Windows: %APPDATA%\Mozilla\Firefox\Profiles\xxxxx.default-release\. Restart Firefox and try again.

If it still fails after all that

Open a new Firefox tab and go to about:config, search security.enterprise_roots.enabled, and set it to true. This makes Firefox read the Windows certificate store instead of only its own. Microsoft's official Firefox MSI build has this on by default — the regular Mozilla build does not. It's a one-line fix for a huge number of corporate setups running TLS inspection.

If that doesn't do it, grab a packet capture. Run Wireshark, filter on tcp.port == 443, and look at what comes back after the ClientHello. If you see HTTP text where a TLS record should be, something upstream — the AV proxy, a captive portal, or a firewall — is injecting plaintext. Captive portals at hotels and airports trigger this constantly, so if you're on guest Wi-Fi, try a tethered hotspot first before you rip apart your config.

One more thing: this error also shows up when you hit an HTTP port with an HTTPS URL, or an HTTPS port with an HTTP URL. If you're testing against an internal dev server, double-check the scheme and port before blaming the AV.

And if you're on Firefox 120+ with DNS over HTTPS enabled, an internal-only site can also fail this way if the DoH resolver can't see it. Check Settings → Privacy & Security → DNS over HTTPS and set it to Off for a quick test.