Getting a SSL_ERROR_RX_RECORD_TOO_LONG error on some site on commercial wifi with portal

dr_no7's Avatar


18 Nov, 2020 05:08 PM


I have been using my loyal Powerbook G4 & TFF FPR 28 with one of those public/commercial wifi access with portal. I ran into a weird situation on sites like, or that are returning a SSL_ERROR_RX_RECORD_TOO_LONG error.

I suspect that they are using some sort of proxy server that interferes with the SSL chain and push it over the edge.
However, some https services (like are still able to establish a proper connection and loads properly.

The big question is: is this length limit adjustable when necessary or is it a hard limit ?

  1. Support Staff 1 Posted by Chris (chtrusch... on 22 Nov, 2020 11:17 AM

    Chris (chtrusch)'s Avatar

    It's possible that the public wifi access is misconfigured or blocking ports or certain protocols or sites or TLS versions.

    It's interesting to note that Mozilla, Wikipedia and Google all use TLS 1.3 if the client supports it (and fall back to 1.2 if it doesn't), whereas uses TLS 1.2 exclusively. You could try to (temporarily) set security.tls.version.max to 3 in about:config, which forces everything back to TLS 1.2, which is still 'secure enough'.

    If that doesn't help, you should try to use another computer running a recent Firefox and OS version and see if the error happens there as well. If so, there is nothing you can do except to tell the admin of the public wifi about the problem (if possible) and ask them to configure their access point properly.

    If it works with a modern Firefox version please report back here.

  2. 2 Posted by dr_no7 on 22 Nov, 2020 03:39 PM

    dr_no7's Avatar

    Hi Chris,

    thanks for the feedback. This network is horrendous so no surprised if it is half-misconfigured and half-outdated filtering.

    The additional tests are a mixed bag. On the good news side, a Firefox 83 under win10 on the same network and the usual suspects are connecting fine. I have attached the connection status from the FF 83 + the cert chain as seen by FF once connected.
    On the bad news side, I forced the TLS level as documented and I get the same error (even after several restart of TFF). For the sake of completeness, I downloaded TFF FPR29 and got the same result (with and without the limit to 3). I tried to use the developer network tool to get more insight on the TLS handshake but it was not providing more information.

    If necessary, I can try to find an older version of WireShark and run a packets dump of the traffic when opening the connection to wikipedia if it can shed more light on what happens.
    Surprisingly, the Radaris information was not showing a much shorter key (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS 1.2) than wikipedia with FF 83 (TLS_AES_128_GCM_SHA256, 128 bit keys, TLS 1.3), just a different set of ciphers.

  3. Support Staff 3 Posted by Chris (chtrusch... on 28 Nov, 2020 03:20 PM

    Chris (chtrusch)'s Avatar

    Can you try Leopard Webkit with your 10.5 PowerBook G4?

  4. 4 Posted by dr_no7 on 11 Dec, 2020 12:30 PM

    dr_no7's Avatar

    Turns out I ran out of time and my access expired (few days before moving out anyway).
    This ticket can be closed as "unreproducible" for now until somebody else run into such weird commercial access point config.

    Thanks for the help =)

  5. Support Staff 5 Posted by Cameron Kaiser on 16 Dec, 2020 10:21 PM

    Cameron Kaiser's Avatar

    Okay. If you can trigger it again, any reply to this ticket will reopen it.

  6. Cameron Kaiser closed this discussion on 16 Dec, 2020 10:21 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac