Your website uses a terrible HTTPS config.
https://www.ssllabs.com/ssltest/analyze.html?d=www.backblaze...
No PFS, weak RC4, TLS 1.0 only, and SHA1.
It's not much effort to fix these, really. It makes me question the security of your product.
https://www.ssllabs.com/ssltest/analyze.html?d=www.backblaze...
No PFS, weak RC4, TLS 1.0 only, and SHA1.
It's not much effort to fix these, really. It makes me question the security of your product.
Firefox cannot guarantee the safety of your data on www.backblaze.com because it uses SSLv3, a broken security protocol. Advanced info: ssl_error_no_cypher_overlap
Firefox 35, rc4 disabled
As far as I understood you should not (especially not only) use rc4. https://en.wikipedia.org/wiki/RC4 even cloudflare is trying to get used of rc4. https://blog.cloudflare.com/killing-rc4/
> Fast-forward to 2013 and attacks on RC4 have been demonstrated; that makes the preference for RC4 problematic.
I don't think it's even possible to run IE6 on Windows Vista or Windows 7 or Windows 8, but I'm not entirely sure of that.
The intermediate suite (default) says: "Firefox 1, Chrome 1, IE 7, Opera 5 and Safari 1. " The "Old backward compatibility" has IE6, but it also has SSL3, which is really not recommended.
Keep checking back, I swear you will see improvement over the next week.
It doesn't inspire confidence that you're still working at enabling TLS 1.2 or some AES ciphersuites with PFS. ... and at de-prioritizing RC4 if you need to keep it enabled. (A competitor, crashplan, seems to think 3DES is enough to support older clients; they've disabled RC4 completely. Mozilla thinks so too, even in their "old backward compatibility" recommendations: https://wiki.mozilla.org/Security/Server_Side_TLS )
If it was a site that had critical user information, like email or document storage, then they could solve this by making their website open to all protocols and then test the browser type and redirect the user to a specific subdomain with the appropriate security. For instance, https://sitename.com could be backwards compatible. Upon login, it redirects the user to lowsecurity.sitename.com or highsecurity.sitename.com depending on their browser type.
The fact that the actual backups may (don't know) be transferred over a channel with higher security is irrelevant if the passphrase for decrypting the backup (or decrypting the decryption key, depending on how it works) is transmitted over SSL to the website in question.
You don't need lowsecurity.site.com and highsecurity.site.com. You can support any even marginally secure and up-to-date client with one website ssl configuration. The big websites do it just fine. The other problem is that clients that don't support TLS 1.2 and good ciphersuites are pretty much by definition no longer maintained very well.