storagemadeeasy.com - main website

[sindarina]

SSL Server Test Results https://www.ssllabs.com/ssltest/analyze.html?d=storagemadeeasy.com (B)

Cipherscan Results

Target: storagemadeeasy.com:443

prio  ciphersuite   protocols  pfs_keysize
1     AES256-SHA    TLSv1
2     AES128-SHA    TLSv1
3     RC4-SHA       TLSv1
4     RC4-MD5       TLSv1
5     DES-CBC3-SHA  TLSv1

Certificate: trusted, 2048 bit, sha1WithRSAEncryption signature
TLS ticket lifetime hint: None
OCSP stapling: not supported
Client side cipher ordering

Cipherscan Analysis

storagemadeeasy.com:443 has bad ssl/tls

Things that are bad:
* remove cipher RC4-SHA
* remove cipher RC4-MD5

Changes needed to match the intermediate level:
* remove cipher RC4-SHA
* remove cipher RC4-MD5
* consider enabling TLSv1.1
* consider enabling TLSv1.2
* consider using a SHA-256 certificate
* consider enabling OCSP Stapling
* enforce server side ordering

Changes needed to match the modern level:
* remove cipher AES256-SHA
* remove cipher AES128-SHA
* remove cipher RC4-SHA
* remove cipher RC4-MD5
* remove cipher DES-CBC3-SHA
* disable TLSv1
* consider enabling TLSv1.1
* consider enabling TLSv1.2
* use a SHA-256 certificate
* consider enabling OCSP Stapling
* enforce server side ordering

Verdict Quite behind the times, this one. No server-side cipher preference, TLSv1 only, RC4 still active, no Forward Secrecy whatsoever, etc. etc. Review this ticket and the results of the SSL Server Test (the entire page, not just the top), and upgrade to a modern TLS configuration.

[sindarina]

It is also recommended that the site upgrade to always-on HTTPS to avoid posting login information from an insecure page, like it does now.

[sindarina]

Notified via email: jim@vehera.com, support@storagemadeeasy.com. Notified via their GetSatisfaction page, which interestingly happens to document a long history of flawed SSL usage going back years.

Has been automatically acknowledged with a Zendesk ticket.

[sindarina]

The notification on their GetSatisfaction page was removed. Think I've been banned, even.

[jimliddle]

Hi,

Thanks for getting in contact. highlighting security concerns is obviously a good thing and I see from your Twitter account you have been targeting many well known online companies with similar assertions.

Re your banning from Get Satisfaction, that was not us so I can only assume that perhaps the tone of your comments to other companies you may have reported on GetSatisfaction has led to a user ban ? I don't know but as far as I am aware none of our team banned or removed that post, in fact we tried to respond there and only then noticed it had been removed.

Re security, our site is checked each day by Mcafee Secure who attempt all kinds of vulnerability attacks, including cross scripting, browser hijacking, SQL injection, protocol specific attacks etc. If the site passes these test it is marked secure and you can see the current status always at the foot of the site (https://www.mcafeesecure.com/verify?host=www.storagemadeeasy.com). We pay for this service, and if anything is flagged then we fix it and it is re-tested.

We also use SSL Labs our selves to check the site (the same as what you used above).

I believe your assertions are misleading about the security of the site as TLS 1.0 is not insecure but TLS 1.2 is better. We have plan to upgrade our SaaS infrastructure to support TLS 1.2 and Forward Secrecy. These were already underway prior to you getting in touch, but require some planning and migration with regards to the stack.

With regards to the ciphers we are removing RC4 but note RC4 breakage is still "academic". The vulnerability results with regards to RC4 where shown to have more biases than previously thought, so that while an actual theoretical attack requires "only" observing a few millions of connections with the target secret always in the same place, it is still impractical, from the attacker's point of view, in a Web context. Thus, no cookie has been stolen in the wild through usage of RC4.

With regards to the assertions about "flawed" SSL usage on the Get Satisfaction site. This is not true. Those GetSatisfaction posts each have various points with regards to security and SSL and each have been addressed at the time they were raised.

I have no idea how many companies respond to your direct assertions about them but in our case we are happy to respond directly because as I highlighted at the beginning of this response, hilighting security can only be a good thing, but I would argue the way you go about it can be self defeating if the aim is to encourage an interaction with the companies.

[sindarina]

@jimliddle: The aim is not an interaction with companies, but getting them to fix flaws in their SSL configurations. So let me reiterate; your configuration is flawed, and there are things you should fix, right now, without waiting for your stack upgrade.

One; you do not enforce a server-side cipher preference, which means clients get to pick for themselves. This means that they won't necessarily pick the best cipher that they support, but go for something like RC4-MD5 instead. See the SSL Server Test Results. You should enforce a cipher order that prefers AES -> 3DES, and disables RC4.

Two; your certificate was renewed in the second half of 2014, as SHA1, when it was already well-known that these would be deprecated by Chrome. You should have renewed with a SHA2 certificate instead, but you did not, which means that you are getting flagged as using obsolete cryptography by Google Chrome. Have your certificate reissued, or renewed as SHA2.

Three; it has been established for quite some time that posting sensitive data, such as user logins, from HTTP to HTTPS is considered Bad Practice. Yet your login form does exactly this, and it apparently has done so for quite some time, judging from the remarks on your GetSatisfaction forum. Please research why this is considered bad practice, and take appropriate steps. Switching to always-on HTTPS would remove the issue completely.

Four: You can argue about RC4 vulnerabilities being 'academic' all you like, but the fact of the matter is that a) the general consensus is that it is weak, and should be therefore be disabled, and b) you do not need it to serve older clients. Also, RC4-MD5 should've been disabled long ago. For more information, read the notes here; https://github.com/isvsecwatch/httpstracker

Five; Your site gets flagged for the OpenSSL CCS vulnerability (CVE-2014-0224), which is why this ticket has the vulnerability label attached. Most supported versions of Apache should not have this problem, and you should therefore review why yours does. And why it has for almost a year now.

Bottomline is this; even considering the time it takes to plan for and upgrade an existing stack, you are slow to do so. You are making excuses about some of the issues flagged, while ignoring the other issues altogether, even though you claim to be looking at the exact same results on the SSL Server Test.

And you want to have an argument about tone, when the problems are on your side, not mine.

The appropriate response would be to fix the issues instead, and review why they weren't flagged by your internal processes until now.

[jimliddle]

I merely made an initial statement to you with regards to your original posting. I guess I figured what the tone of your response would be given the aggressive nature of your original posting and of your call outs to other companies I observed on Twitter.

I am not prepared to engage in a "flame war" of escalating explanations and responses as I don't see anything objective in your approach to encourage this, and I could respond to each of what you call out there with a reasonable response, such as for example:

OpenSSL CCS vulnerability (CVE-2014-0224) - We are not vulnerable, We are patched. The SSL Labs makes an assumption as it clearly states:

"OpenSSL CCS vuln. (CVE-2014-0224) Probably, but not exploitable (investigate to confirm and patch)"

and I can confirm we are patched.

I could go thorough each of your assertions and provide similar discussions with regards to each but I do not see the point as your objective is not to have a dialogue about any of those points.

As I said in my first post, "thanks for your observations", I do not agree with all your assertions and as I pointed out we frequently do penetration testing, not jus via Mcafee, but also with external PenTest companies and where we can make sensible changes that enhance security we will.

I will not be responding to any further replies.

[sindarina]

Looks like they made some changes; certificate was upgraded, server-side cipher order implemented, chain issue resolved. Not done yet, but it's an improvement.

[sindarina]

Changed 'No Forward Secrecy' into 'Lacks Robust PFS', since that is basically the issue.

[sindarina]

No change.

[sindarina]

In light of the details of the Logjam attack (https://weakdh.org/), we are upgrading 1024-bit DH keys to a red level issue that should be resolved, as that key size puts it within reach of state-level adversaries and is no longer considered safe.

See https://github.com/isvsecwatch/httpstracker#a-note-on-dhdhe for details.

[sindarina]

With today's SSL Server Test changes, this now caps at 'C'; https://www.ssllabs.com/ssltest/analyze.html?d=storagemadeeasy.com

[sindarina]

No change.

[sindarina]

No change; still TLSv1 only, with 1024-bit DH keys.

[sindarina]

No change. Poked on Twitter; https://twitter.com/isvsecwatch/status/617252306795540480

[sindarina]

No change.

[isvsecwatch-report]

Updated to a new configuration that rates as 'A+' on the SSL Server Test; https://www.ssllabs.com/ssltest/analyze.html?d=storagemadeeasy.com

Closing as resolved.