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

dr_no7's Avatar

dr_no7

18 Nov, 2020 05:08 PM

Hi,

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 gmail.com, mozilla.org or wikipedia.org 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 radaris.com) 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 radaris.com 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?
    https://sourceforge.net/projects/leopard-webkit/

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? 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