Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Firefox using "TLSv1 Record Layer" possibly makes company portal inaccessible

more options

Since we switched to a new company portal ("intranet"), I can no longer use Firefox to access it. Chrome and Internet Exploder both work fine (on the very same machine, same network, etc!).

The error message I get is:

An error occurred during a connection to <hostname>. PR_CONNECT_RESET_ERROR

   The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

Somehow this sounds like a certificate verification problem, but if that was really a problem, Firefox wouldn't continue starting the TLS handshake, right? But it does...

I used Wireshark to do network traces, and I can see that after the initial "client hello" the portal web server resets the connection. When I compared the snoop to one captured for Chrome, I noticed that the "client hello" Firefox sends uses a "TLSv1 Record Layer" in the "Client Hello," while Chrome uses a "TLSv1.2 Record Layer" in the "Client Hello."

I set "security.tls.version.min" to "2" already, but that didn't help.

I later also noticed that Chrome offers two TLS_RSA_WITH_AES_xxx_GCM_SHAxxx crypto suites, while Firefox doesn't.

My guess is that one of the above observations is likely the reason why Firefox can't connect.

Does that sound plausible to you? Why the difference in the TLS record layer? Why doesn't Firefox the above cypto suites? Are they considered insecure?

(Before you ask, unfortunately I can't give the host name to our portal, sorry.)

Many thanks for your help, this is really annoying me...

Kr,

Ralf

Since we switched to a new company portal ("intranet"), I can no longer use Firefox to access it. Chrome and Internet Exploder both work fine (on the very same machine, same network, etc!). The error message I get is: An error occurred during a connection to <hostname>. PR_CONNECT_RESET_ERROR The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Somehow this sounds like a certificate verification problem, but if that was really a problem, Firefox wouldn't continue starting the TLS handshake, right? But it does... I used Wireshark to do network traces, and I can see that after the initial "client hello" the portal web server resets the connection. When I compared the snoop to one captured for Chrome, I noticed that the "client hello" Firefox sends uses a "TLSv1 Record Layer" in the "Client Hello," while Chrome uses a "TLSv1.2 Record Layer" in the "Client Hello." I set "security.tls.version.min" to "2" already, but that didn't help. I later also noticed that Chrome offers two TLS_RSA_WITH_AES_xxx_GCM_SHAxxx crypto suites, while Firefox doesn't. My guess is that one of the above observations is likely the reason why Firefox can't connect. Does that sound plausible to you? Why the difference in the TLS record layer? Why doesn't Firefox the above cypto suites? Are they considered insecure? (Before you ask, unfortunately I can't give the host name to our portal, sorry.) Many thanks for your help, this is really annoying me... Kr, Ralf

Modified by Ralf G. R. Bergs

All Replies (4)

more options
more options

Hi Ralf, I don't know of a tool to check what cipher suites your intranet server offers. For public websites, you can use the SSLLabs tool to extract that. https://www.ssllabs.com/ssltest/

more options

jscher2000 said

Hi Ralf, I don't know of a tool to check what cipher suites your intranet server offers. For public websites, you can use the SSLLabs tool to extract that. https://www.ssllabs.com/ssltest/

Hi, thanks for reminding me about that tool, I'm very familiar with it and use it myself since many years. :-)

Actually, our company portal IS available publicly (protected by a login, though), but I don't want to quote the host name here for confidentiality reasons. :-) (I would quote it non-publicly, though...)

Interestingly enough, Qualys shows exactly the same results for Firefox in their simulation that I actually get, see attached. Actually I'm quite happy about that, as it shows it seems to be an actual problem.

more options

If you compare the section of the SSL Labs page that lists the ciphers with what your Firefox shows on their client test page, are there any overlaps?

https://www.ssllabs.com/ssltest/viewMyClient.html