> Which brings us to the most important principle on HN: civility. Since long before the web, the anonymity of online conversation has lured people into being much ruder than they'd dare to be in person. So the principle here is: don't say anything you wouldn't say face to face. This doesn't mean you can't disagree. But disagree without calling the other person names. If you're right, your argument will be more convincing without them.
We got a B! That's above average! Totally not "terrible". Truth is the website and the service itself are fairly different, but I can tell you that we have a lot of folks using, lets say..."older", browsers that access our site, and so we try to make sure that they can still access their accounts - though we're constantly monitoring for ways to make it better. A lot of folks that use us have older operating systems and that hampers us a bit.
Brian from Backblaze here. Which browser was that? We often test with Mac/Windows and Safari/Chrome/IE/Netscape/Opera, etc. It all seems to work here. Did you tweak any browser settings or are you running stock?
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
If you look at the ssllabs analysis, they already fail in IE 6 handshake simulation. Offhand I can't say if support for older browser is incompatible with more modern ciphers and protocols.
Brian from Backblaze here. Why do we get a bad grade for not talking with IE6? I'm honestly curious... I thought anybody who supported IE6 should be downgraded, because IE6 was end of lifed, inherently using it is a bad bad bad thing. It is literally safer to not use it than use it, right?
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.
Instead of patting yourself on the back based on your interpretation of an arbitrary letter grade, can you please do some research into the problems flagged by ssllabs and fix them? Supporting older browsers does not preclude supporting modern ciphersuites and TLS versions for new browsers.
Brian from Backblaze here. We are aware of the sslabs flagged issues and we're working to keep on top of it. Sometimes these issues apply to Backblaze and we are vulnerable for a short time (like when HeartBleed came out we had to scramble to plug it as fast as humanly possible). But most of the time when we are slightly slow it is because it doesn't REALLY affect our customers or us.
Keep checking back, I swear you will see improvement over the next week.
I don't think there are any acute issues like heartbleed (other than the possibility that RC4 is completely broken to secure against state-level adversaries, or that your ssl key might be compromised now or in the future), but the downvoted-to-hell points made higher up are that you should have been aware enough of best practices to improve your ssl config a long time ago.
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 )
Their website doesn't have a lot to protect, in all honesty. Their backup product uses different security mechanisms.
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 login password is the primary backup password isn't it? That's what would enable them to offer downloads of backed-up files. While they have a zero-knowledge option (encrypt using secret key only known to the client), it can't realistically be enabled by default in a backup service that's intended to be easy to use. Same with crashplan and every other service that isn't zero-knowledge-mode only.
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.
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.