Getting a SSL_ERROR_RX_RECORD_TOO_LONG error on some site on commercial wifi with portal
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 ?
Comments are currently closed for this discussion. You can start a new one.
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
Support Staff 1 Posted by Chris (chtrusch... on 22 Nov, 2020 11:17 AM
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 Posted by dr_no7 on 22 Nov, 2020 03:39 PM
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.
Support Staff 3 Posted by Chris (chtrusch... on 28 Nov, 2020 03:20 PM
Can you try Leopard Webkit with your 10.5 PowerBook G4?
https://sourceforge.net/projects/leopard-webkit/
4 Posted by dr_no7 on 11 Dec, 2020 12:30 PM
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 =)
Support Staff 5 Posted by Cameron Kaiser on 16 Dec, 2020 10:21 PM
Okay. If you can trigger it again, any reply to this ticket will reopen it.
Cameron Kaiser closed this discussion on 16 Dec, 2020 10:21 PM.