User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160623154057 Steps to reproduce: Attempt to access a certain site using a synchronized profile. Actual results: HTTPS certificate retrieval immediately failed, unknown cause. Expected results: Retrieved the certificate and continued with the usual checks and page loading.
New, unsynchronized profiles behave normally, however using my current sync'ed profile will result in the retrieval failure accessing at least pccasegear.com. Attempting to access the site normally results in the generic "secure connection failed" page, no certificate details (only try-again is present). exceptionDialog.xul returns "no information available", nothing obvious in the debugger, however ff doesn't even attempt to request the cert (no network activity). All the usual cache clearing, DNS caching disabled, cert database flushing, etc has been performed to no avail.
Severity: normal → blocker
Component: Untriaged → Security
Are you using a proxy of some kind to connect? Can you include a packet trace of the failed connection?
Component: Security → Security: PSM
Product: Firefox → Core
No proxy is used, normal direct connection, running ff on the same system with a different profile via the -profile argument results in normal page load behavior, so it's profile-specific. Same problem occurs on any other system using my synchronized profile. As for packet trace, I assume you mean the results in the network tab of the web console/debugger? The only thing displayed is a GET to www.pccasegear.com that fails to transfer (0KB size, <0ms time, strike through transmit). Screenshot for clarification; http://prntscr.com/bydc9o Don't actually know if this is in security or it may actually be with the DNS system, or even another system, it's just failing to handle the site completely in just this sync'ed profile... I will also note though that I just discovered that the Content, Applications, Security and Sync options pages just suddenly stopped working, no idea how that happened and probably completely unrelated...
Sorry, I meant with wireshark or tcpdump or similar: https://www.wireshark.org/ (just use a capture filter of "host www.pccasegear.com")
Created attachment 8775365 [details] pccasegear tcp dump.pcapng Packets that wireshark captured when trying to obtain the certificate in exceptionDialog.xul, so DNS is confirmed working correctly at least.
Thanks - it looks like that profile has disabled TLS 1.1 and 1.2. Since www.pccasegear.com doesn't appear to support TLS 1.0, it just closes the connection. If you go to "about:config" and search for "security.tls", I would make sure all of those preferences are set to their default values. Alternatively, you might try out Dev Edition: https://www.mozilla.org/en-US/firefox/developer/ (we recently developed a feature that offers to reset these preferences when the browser encounters an error like this and the prefs aren't their default values).
Turns out it was security.tls.version.max set to 1, instead of the default 3, completely unknown how or why it was set to that. Additionally it's a little odd that it only affected this one site... Provided new versions will adequately fix this kind of issue via resetting the required settings as mentioned, this can be closed. However would we want this to be noted on the site somewhere? I ended up opening this ticket simply because I couldn't find anything about this particular kind of issue.
Good to hear that's sorted out. I think I'll just mark this as a duplicate of the bug that added the pref reset feature. (In reply to Paul17041993 from comment #7) > However would we > want this to be noted on the site somewhere? On pccasegear.com? You might open up a Tech Evangelism bug or ping them on twitter, but other than that I'm not sure there's much we can do.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1252068
You need to log in before you can comment on or make changes to this bug.