Can you post a link to a publicly accessible page (i.e. no authentication or signing on required)?

If you can't inspect the certificate via Advanced (I Understand the Risks) then try this:

Open the "Add Security Exception" window by pasting this chrome URL in the Firefox location/address bar and check the certificate:

• chrome://pippki/content/exceptionDialog.xul

In the location field of this window type or paste the URL of the website with the https:// protocol prefix (https://xxx.xxx).

• retrieve the certificate via the "Get certificate" button
• click the "View..." button to inspect the certificate in the Certificate Viewer

You can inspect details like the issuer and the certificate chain in the Details tab of the Certificate Viewer. Check who is the issuer of the certificate. If necessary then please attach a screenshot that shows the Certificate Viewer with the issuer.

You can check the ssl and tls prefs on the about:config page to make sure that they are all default. If any ssl or tls pref is bold (user set) then right-click that pref and choose "Reset" to reset the pref to the default value. Paste this regular expression in the Search bar at the top of the about:config page:

• /security.*ssl|security.*tls/

Leave these prefs set to false on the about:config page to disable cipher suites that are involved with the Logjam vulnerability in case they are currently enabled (true).

• security.ssl3.dhe_rsa_aes_128_sha
• security.ssl3.dhe_rsa_aes_256_sha

Hi cor-el,

Thank you very much for your detailed response.

The SSL certificates I purchased and installed from Comodo. Those are legitimate and working. The websites themselves are authentication based.

I've attached the changed settings for the SSL to match closer to the PCI compliance, and the TLS settings I change from yesterday.

I've also attached a screen shot of the handshake between Firefox and the server itself in contrast to other devices/browsers.

Thanks.

I think that's the SSLLabs test page in your third screen shot. If you check their "Cipher Suites" list, can you find overlap with the list in about:config?

Hi jscher2000,

I removed the other 2 RC4 cipher suites from the about:config leaving just the ECDHE. You are correct, I used the QUALYS test for this particular environment. The server itself is using a couple extra suites, but the ECDHE takes priority as it being the strongest available currently.

It just seems like if there is no fallback for Firefox to go on, it simply gives up the connections - I receive the Secure Connection error almost instantly.

EDIT: I tested the 2 websites on my phone with the built-in (horrible) browser and that worked. I used Chrome and Opera with no issues either. I installed Firefox a la carte and it gives me the same problem, so it's completely isolated to how Firefox emulates the handshakes on the given protocols.

Thanks.

It's puzzling. I assume SSLLabs used Firefox 31/42/44 with their default settings when reporting that "Server Closed Connection." There must be something else going on here. Do you have any logs on the server side that might help in debugging a refused connection?

I think you actually didn't answer my question --

I think that's the SSLLabs test page in your third screen shot. If you check their "Cipher Suites" list, can you find overlap with the list in about:config?

-- so let me state it another way. Does the server allow at least one of the ciphers listed in about:config?

I'm attaching a comparison from SSLLabs with my Firefox preferences for my website, which makes no attempt at PCI compliance, showing the cipher used which is enabled by default.

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

Added list of ciphers detected as supported by the server.

Hi jscger2000,

Using your screenshot as the guide for this, and also despite running just the top cipher suites only, I do have both sets matching; unfortunately with the same results.

Firefox just updated to v46 upon writing this post out. I will test again and make another comment if yes/no.

Thanks.

EDIT: Firefox 46.0.1, same issue.

EDIT #2: Upon further investigation between your screenshot, mine and another server I completed, I believe I might have the answer. Firefox does not natively support cipher suite encryption levels above SHA. The server having the issues has the SHA suite completely disabled leaving 256bit keys and above enabled, even with the AES 128 wrapper on a couple of the suites. I will make this change tonight and verify if this is the answer.

I apologize for not getting back, but my suspicion is now CONFIRMED. Firefox does NOT support cipher suite encryptions above SHA, regardless of wrapper.

All websites are working after the switch for SHA was enabled again. This should be brought up to the developers immediately - especially since I tried to access a couple government sites, and was forced to use Chrome due to the issues I was facing.

professordns said

This should be brought up to the developers immediately - especially since I tried to access a couple government sites, and was forced to use Chrome due to the issues I was facing.

Do you happen to recall what sites those were? That would be useful in filing a bug to see whether they are well-configured or whther the problem was that you disabled the RC4 ciphers and those sites are not yet updated to use more secure ciphers.

I assume that this is about specific SHA256 and SHA384 cipher suites that Firefox doesn't support.

• http://mxr.mozilla.org/mozilla-release/source/security/nss/lib/ssl/sslenum.c