Closed Bug 1140919 Opened 5 years ago Closed 5 years ago

www.inboxtech.co.za is RC4 and Camellia only

Categories

(Web Compatibility :: Desktop, defect)

Firefox 36
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mzqasim, Unassigned)

References

()

Details

Attachments

(1 file)

Attached image problem ssl.jpg
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
Severity: normal → critical
Component: Untriaged → Security
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
Status: UNCONFIRMED → NEW
Component: Security → Desktop
Ever confirmed: true
Product: Firefox → Tech Evangelism
Summary: SSL not working in only firefox browser since after update 36.0.1 → www.inboxtech.co.za is RC4 and Camellia only
Version: 36 Branch → Firefox 36
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.
Severity: critical → normal
OS: Windows 8.1 → All
Hardware: x86_64 → All
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
Blocks: 1143254
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.
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.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → 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.
Status: RESOLVED → VERIFIED
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
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.