User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150211222327 Steps to reproduce: User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox /38.0 Build ID: 20150211222327 Tried to visit https://www.cyta.com.cy (homepage of my ISP) Actual results: Fx 38 "Secure Connection Failed" Fx 38 with Add-Ons disabled "Secure Connection Failed" Fx 38 with new profile "Secure Connection Failed" Fx 37 "Secure Connection Failed" (Before latest update the error was "Connection was reset") Fx 36 Loads normally Fx 35 Loads normally Chrome 40 Loads normally IE 11 Loads normally Opera 25 Loads normally Expected results: It should load normally.

Works fine for me on 38.0a1 (2015-02-12) Win 7. Please check if the issue occurs using Firefox in safe mode (with your addons disabled): http://support.mozilla.com/kb/Safe+Mode And on a new, empty profile: http://support.mozilla.org/en-US/kb/Managing-profiles#w_starting-the-profile-manager

(In reply to Paul Silaghi, QA [:pauly] from comment #1) > Works fine for me on 38.0a1 (2015-02-12) Win 7. > > Please check if the issue occurs using Firefox in safe mode (with your > addons disabled): > http://support.mozilla.com/kb/Safe+Mode > > And on a new, empty profile: > http://support.mozilla.org/en-US/kb/Managing-profiles#w_starting-the-profile- > manager Hey Paul! Thanks for your investigating. As you may see in my original post I've already tried your suggestions with no luck. Testing it again with today's build seems to work, though. Thanks again for your trouble! Thanks again!

Hey Paul again! Sorry to bother you but could you test it again with 2015-02-15 build? (BuildID 20150215030238) I get the same error again and I'm not sure if something has changed with the latest build or with their site. Thanks!

For the record: Still having problems with the build of Feb 16 (Build ID: 20150216030222)

This site restricts the cipher suites to RC4 or AES_CBC_SHA256. Probably the site is misunderstanding the deprecation of SHA1. It doesn't make sense to restrict the hash function to HMAC_SHA256. HMAC_SHA1 is still considered enough strong, unlike plain SHA1. Moreover, it doesn't make sense to restrict cipher suites at all if it still allows RC4.

Hm, SSL Labs couldn't detect the cipher suite correctly? My local build can connect with TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.

Works for me now.

(In reply to Masatoshi Kimura [:emk] from comment #7) > Works for me now. Hi Masatoshi Kimura! Unfortunately it still fails for me with last Nightly update (Build ID: 20150221030208). Tried also with Add-ons disabled and with a new profile without any luck. If there are any more confirmations then I will assume it's my problem/setup. Thanks!

Maybe because of some intermediates (such as a proxy server) between you snd your ISP. Could you try the following step? 1. Open about:config. 2. Click-through the warning. 3. Type "tls" into the search box. 4. Double click "security.tls.insecure_fallback_hosts". 5. Type "www.cyta.com.cy" into the box. 6. Click "OK". 7. Try to access <https://www.cyta.com.cy>.

ESR 31.4.0 win32: good 35.0.1 win32 security.tls.version.fallback-limit = 1: good security.tls.version.fallback-limit = 2: good security.tls.version.fallback-limit = 3: good 36.0 RC win32 security.tls.version.fallback-limit = 1: good security.tls.version.fallback-limit = 2: good security.tls.version.fallback-limit = 3: good 37.0a2 win64 (20150221004230, rev:f23746928e84) security.tls.version.fallback-limit = 1: good security.tls.version.fallback-limit = 2: good security.tls.version.fallback-limit = 3: bad security.tls.version.fallback-limit = 3, security.tls.insecure_fallback_hosts: good 38.0a1 win64 (20150221030208, rev:5de3af90c494) security.tls.version.fallback-limit = 1: good security.tls.version.fallback-limit = 2: good security.tls.version.fallback-limit = 3: bad security.tls.version.fallback-limit = 3, security.tls.insecure_fallback_hosts: good Now, SSL Labs test says as below: TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes SSL 3 INSECURE Yes SSL 2 No TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 521 bits TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 521 bits TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 521 bits TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 521 bits TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_RC4_128_SHA (0x5) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) TLS version intolerance No

(In reply to Masatoshi Kimura [:emk] from comment #9) > Maybe because of some intermediates (such as a proxy server) between you snd > your ISP. > Could you try the following step? > 1. Open about:config. > 2. Click-through the warning. > 3. Type "tls" into the search box. > 4. Double click "security.tls.insecure_fallback_hosts". > 5. Type "www.cyta.com.cy" into the box. > 6. Click "OK". > 7. Try to access <https://www.cyta.com.cy>. 1. No proxy server set. 2. Trying what you suggested (adding www.cyta.com.cy to security.tls.insecure_fallback_hosts) solves the problem. One comment for what it's worth: If I reset the setting to empty string (as it was originally) https://www.cyta.com.cy is still accessible to the end of the session (i.e. until Nightly is closed). Once restarted the problem repeats and the URL has to be added to the setting again. The above applies also for Fx Developers' Edition (i.e. problem solved with the addition of the host to the security.tls setting) Thanks a lot for your working on this/help!

I reproduced the connection error when I visited the site from another location. Reopening to investigate further.

Still broken for anyone? WFM (connects using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) on Aurora 39 with both used and clean profiles.

Also WFM in Aurora 39.

Works fine for me both in 39 and 40 with used and clean profiles. Thank you!

Closing per the latest comments.