User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150305021524 Steps to reproduce: i contact with my ssl provider and hosting provider as well but both said that its a firefox browser problem because ssl working fine in all other browsers. Actual results: SSL not working and not showing padlock at left side of url bar just after browser updated to 36.0.1 Expected results: SSL should work fine and padlock should be shown at left side of url bar

That's because the server (effectively) supports only the insecure RC4 encryption algorithm. This change was introduced to Firefox 36 to warn broken servers. And this is yet another *.unifiedlayer.com instance. https://www.ssllabs.com/ssltest/analyze.html?d=www.inboxtech.co.za

ok, but what should be the solution for fixing that issue??

Please ask your hosting company (I guess that's Hostmonster) to update their server settings. They should add something better than RC4 and actually supported by browsers (virtually no browsers support Camellia anymore).

No its bluehost and their support is awfull :( Last time i got the ticket reply after 30 days :( Please tell me any other solution. Although i created a ticket with them but i don't think so they will solve out this soon because their support is too bad :(

(In reply to zubair from comment #4) > Please tell me any other solution. RC4 has been banned by the IETF. It's not secure and is being phased out by everyone. http://tools.ietf.org/html/rfc7465 All browsers will stop supporting it eventually; it's just a matter of how quickly. Firefox is just stalling the least. Based on the test in comment 1, the server in question is far better off than a lot of the crap we've been hearing about. It supports TLS 1.2, however it has the mandatory to implement cipher suite disabled. (TLS_RSA_WITH_AES_128_CBC_SHA) The solution is simply to turn that back on.

but what should i say to my host provider for solving out this issue??

Point them here. This is a broad problem they need to fix for all of their clients. Ideally, they should be responding here instead of you. In the near future, servers configured in this manner will not be compatible with any browser. They need to (re)enable viable ciphers. Basically any AES-based cipher will be fine. (in the future there will be more options) The minimum is the mandatory cipher they have disabled. Ideally, they should use ECDHE-RSA-AES128-GCM-SHA256 or similar. They already support the necessary protocols. It's just a matter of configuring it properly.

Hi i provided this issue link to bluehost. i hope they will see here and resolve the issue soon. somebody from bluehost please reply here for confirmation that bluehost is aware of this problem which should be resolve as soon as possible

i added SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256 in .htaccess and after the Firefox opening my website but Internet Explorer 11 not opening the website. some body have any idea about this issue? thanks

Internet Explorer 11 on Windows 8.1 does not support ECDHE-RSA-AES128-GCM-SHA256 (Windows 10 will). You will also need ECDHE-RSA-AES128-SHA to support Internet Explorer 11. And I didn't know Bluehost allowed users to set SSLCipherSuite. Thanks for the useful information!

IE seems to have iffy support for GCM cipher suites. https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%208.1 IE11 seems to be able to do: DHE + RSA + AES-GCM RSA + RSA + AES-GCM ECDHE + ECDSA + AES-GCM but NOT: ECDHE + RSA + AES-GCM That's kinda stupid, but that's not an unusual thing to say when examining IE. Looks like you'll need to support ECDHE+ECDSA or DHE+RSA to get IE working with AES-GCM. (you don't want plain RSA if you can avoid it) You don't need to fiddle with the exact suites to support everything correctly yourself. Just use this: https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility a server config wizard is here: https://mozilla.github.io/server-side-tls/ssl-config-generator/

i tried everything but still i am getting the following error in internet explorer 11 This page can’t be displayed •Make sure that the web address https://www.xyz.com is correct. •Look for the page with your search engine. •Refresh the page in a few minutes.

Please paste the result when you access <https://www.ssllabs.com/ssltest/viewClient.html> using Internet Explorer 11.

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

Protocol Support Your user agent has good protocol support. Your user agent supports TLS 1.2, which is the best available protocol version at the moment. FREAK Vulnerability (Experimental) Your user agent is not vulnerable. For more information about the FREAK attack, please go to www.freakattack.com. To test manually, click here. Your user agent is not vulnerable if it fails to connect to the site. POODLE Vulnerability Your user agent is vulnerable. You should disable SSL 3. For more information about the POODLE attack, please read this blog post. Protocol Features Protocols TLS 1.2 Yes TLS 1.1 No TLS 1.0 Yes SSL 3 Yes SSL 2 No Cipher Suites (in order of preference) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Forward Secrecy 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) Forward Secrecy 256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) Forward Secrecy 128 TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Forward Secrecy 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Forward Secrecy 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x6a) Forward Secrecy2 256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x40) Forward Secrecy2 128 TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38) Forward Secrecy2 256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Forward Secrecy2 128 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) Forward Secrecy2 112 (1) When a browser supports SSL 2, its SSL 2-only suites are shown only on the very first connection to this site. To see the suites, close all browser windows, then open this exact page directly. Don't refresh. (2) Cannot be used for Forward Secrecy because they require DSA keys, which are effectively limited to 1024 bits. Protocol Details Server Name Indication (SNI) Yes Secure Renegotiation Yes TLS compression No Session tickets Yes OCSP stapling Yes Signature algorithms SHA256/RSA, SHA384/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, SHA1/ECDSA, SHA1/DSA Elliptic curves secp256r1, secp384r1 Next Protocol Negotiation Yes Application Layer Protocol Negotiation Yes SSL 2 handshake compatibility No Mixed Content Handling Mixed Content Images Passive Yes CSS Active No Scripts Active No XMLHttpRequest Active No WebSockets Active No Frames Active No (1) These tests might cause a mixed content warning in your browser. That's expected. (2) If you see a failed test, try to reload the page. If the error persists, please get in touch.

(In reply to zubair from comment #15) > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) Forward Secrecy 128 Hm, DHE-RSA-AES128-GCM-SHA256 should work. That's strange... (Note that ECDHE-ECDSA variants will not work unless you have an EC certificate.)

not working, getting same following error with IE11/Win8.1 This page can’t be displayed

Could you provide a test url? I'll test with IE11 myself.

webexpert.co.za

I can connect it with IE11 and cannot connect with Nightly.

what is Nightly??

https://nightly.mozilla.org This is the latest development version of Firefox.

try to open www.webexpert.co.za with firefox 36.0.1 the website will be open but caution mark will come instead of padlock on the other end, open the same website with IE11, the website will be open but here you will see ssl padlock i don't use nightly and i don't think so that i need to use it.

Then SSLCipherSuite has no effect on your server. You will have to wait for a response from Bluehost.

i got the response below from bluehost Hello, I apologize for the trouble you are experiencing. We are still working to have RC4 disabled but it will take some time before those changes are rolled out. The second set of .htaccess directives added is the recommended cipher suite for backwards compatibility with IE6/WinXP and should work for IE11 as well. I would suggest checking with Microsoft support for help in resolving that. You can also see this page for more information on this change: https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html Thank you, Jesse Level II Tech Support Engineer BlueHost.com 888.401.4678

Bluehost suggested me the following but thats also not working with IE11 :( SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4

You fail to change the setting somehow because your site is still RC4-only.

So i must wait for until bluehost completely disable RC4 ??

anybody have solution for my problem????

Your host provider is simply using an obsolete and insecure cipher and has to upgrade to something modern. There's not much else anyone here can do to help you with that. I've made some attempts to contact them and get them to reply in bug 1143254, but nothing yet. Whitelisting some of their domains for RC4 might be warranted when Firefox switches to prohibiting RC4 usage generally, but at the moment you're just getting a warning, which is entirely valid.

I contacted bluehost, hopefully they will reply their position at https://bugzilla.mozilla.org/show_bug.cgi?id=1143254

Fixed.

RC4 is gone and quite a few better cipher suites are now supported. AES-GCM suites are available now too, however, the server is prioritizing them weirdly. Firefox, Chrome, IE, and Safari all negotiate CBC instead of GCM as a result.

Hi Dave So the problem is resolved now? and everything is running perfectly? please confirm

Yes. Masatoshi closed this as FIXED and I also checked it and marked it as VERIFIED. The server is now graded 'A' here: https://www.ssllabs.com/ssltest/analyze.html?d=www.inboxtech.co.za This is a very good improvement. Lots of green in the tests now. :) Ideally, the server's cipher suite preferences should be adjusted to prefer GCM over CBC. Firefox prefers GCM, but the server get's the final say in the negotiation. With the way it's configured now, no browsers actually get GCM even though it is actually supported by the server. There is a single GCM suite ranked above CBC, but nobody supports it; the rest are ranked after it. This is probably a misconfiguration. Technically speaking, CBC in TLS is cryptographically broken and everyone should be using GCM (or another AEAD mode). However, it's still generally considered acceptable and not likely to lose browser support anytime soon (probably). Very recent updates to NIST's vuln scoring require RC4 and also TLS 1.0 to be disabled for PCI compliance, however I don't know if you're affected by that or not. Nobody is really on-board with a total deprecation of TLS 1.0 yet; it was a side affect of their re-scoring to deal with RC4. In an ideal world, I'd recommend disabling it, but it's still often needed to support older browsers. HSTS and some other newer stuff really should be supported as well, but it does work fine without it. (the test does go up to 'A+') So, not "perfectly", but more than sufficient for this issue here.

alright Dave thanks for your support thanks to Masatoshi as well :) regards