April 8, 2014

SpiderOak.com and related SSL certificates were changed yesterday due to the OpenSSL Bug

by with 10 comments

As has been widely published, a significant vulnerability has been found in OpenSSL, the transport encryption library used by many SSL websites. SSL is the mechanism that encrypts your browser’s connection to the server, verifying the server’s identity and preventing eavesdropping. Many people know it as the padlock icon in a web browser.

Many sites across the internet including Amazon, GitHub, Heroku have likewise changed their certificates.

SpiderOak patched our OpenSSL servers within a couple hours of the announcement yesterday. The SpiderOak desktop clients ship with a version of OpenSSL that is not subject to this vulnerability. As such, SpiderOak customers do not need to take any special action.

More info about the vulnerability is at heartbleed.com.

Comments
  1. If we have ever used our password to log in to the website, should we then change our passwords within the client?

    • The fact that they’ve changed their certificate suggests that, yes, the web server was vulnerable, and that, yes, passwords should be changed if they’ve been used via the web interface.

      The exploit (as I understand it) allowed an attacker to see some of what was stored in the memory of the server when the attack was made. The reason people are changing certificates is because it’s possible that the server may have divulged the private keys used to generate certificates. The certs were still good, but could possibly be forged. Hence the private keys need to be regenerated, and certificates regenerated.

      Passwords are something that could be divulged in the same manner, if they were in the memory of the server at the time of an attack.

      Fortunately SpiderOak is zero knowledge (unless you’re using the web interface, including mobile clients), so their servers don’t have any knowledge to divulge.

      • Thanks Paul; this analysis is correct. The backend server (which actually handles storage login) is not the same operating system process as process that terminates SSL, so thankfully there are some limits to what information could have been captured from the SSL process. For example, the SSL process wouldn’t get to learn any of the lower level encryption keys that your password protects. But unfortunately the SSL process necessarily does get to see everything that goes over the wire, including passwords. The SpiderOak servers were not vulnerable for very long after the vulnerability was announced, but of course if bad people independently discovered this vulnerability earlier, they could have exploited it.

        The headline I saw earlier today “internet users advised to change all passwords” is pretty accurate.

        To be clear, if you never used the SpiderOak website for storage login, and only accessed data through the SpiderOak desktop software, you would not be affected by this.

        Hope that makes sense.

        Also, here’s Bruce’s take on the whole Heartbleed siutation: https://www.schneier.com/blog/archives/2014/04/heartbleed.html

        • Alan, although the storage login itself is not directly vulnerable, if, as per the above, we may at any point over the past couple years have had our passwords compromised should we have logged into the website directly with them, could that compromise of our passwords not then also expose our encryption keys?

          How precisely the storage login works I do not know (perhaps something I should look into); does any aspect currently (or in previous code versions) involve a copy of the encryption keys being sent to the client application? Specially what I’m getting at is – could a sufficiently resourceful party (such as intelligence services) with a copy of our password per the above, not compromise our encryption keys? Or would they be limited to only accessing content of our account until such time that we change our password? (I’m somewhat doubting the latter since surely data is encrypted locally with our encrypted key before being uploaded).

          If there’s any chance that our encryption keys could have been compromised, then those of us that truly value our privacy really need to get them changed. I understand that this may put a hell of a strain on the spideroak service, but if what I’m saying is possible, it’s a necessity.

          What are your thoughts on this?

        • Furthermore, since the default sign-up/registration mechanism on the website requires a password, it’s entirely possible that each and every new user over the past couple years may have been compromised, not just those that have logged in to the website in the manor described above. Is it even possible to create an account with the application directly, I forget, but even if it is, I expect that most people would sign up on the website, as they are used to doing (I know I did).

          • The password sent during signup is actually bcrypted by the browser before being sent to the server. So a passive heartbleed listener wouldn’t get the plaintext of the new account signup passwords. That would typically require an active MITM attack. An MITM attack on SpiderOak.com would require a CA, since spideroak.com uses HSTS. If the attacker can do that they can probably cause you lots of other problems too.

            Regarding how the server and clients communicate, they do not talk to SpiderOak.com, but rather use a separate SSL termination proxy that has never been vulnerable to heartbleed.

            The mobile logins and web logins do send passwords to the server, and those could have been intercepted. If an attacker wanted to make an active attack, they could then use those passwords to create a new device on your SpiderOak account, and download your data.

            If an attacker had gone that far, changing your password wouldn’t be a sufficient remedy. Password changes do not re-upload and re-encrypt all existing data with the new password. They change the top level wrapping key. Other keys below that remain unchanged. (To do otherwise would invalidate all previous backups.)

            In that extreme of a situation, the only appropriate solution is to start over with a new SpiderOak account. If you want to do this, email support, and they’ll be happy to transfer your billing history from your old account to a new SpiderOak account, let you upload your data again, and then cancel the old account after the upload is complete, without any service interruptions.

  2. I wanted to thank you for also updating your website to support PFS – I was always a bit surprised that you did not support this for a long period. Glad to see the updates all around!

  3. So yesterday I tried enabling 2 factor authentication but had a typo in the mobile number upon requesting a token. I realized the error after not receiving a token via SMS. I corrected the number and tried resubmitting for a token several tiimes. It never arrived. Today I tried logging in to my account but I’m getting an “Invalid username or password.” I e-mailed tech support expressing concern that 1) there is a problem with 2FA setup, and 2) I’m concerned that someone possibly gained access to my account due to me initially submitting the wrong mobile number. They simply disabled 2FA for my account and said that my account should work now. I quickly tried but still get the “Invalid username or password.” error, and reported as such. I didn’t change my password which heightens my fear that someone else gained access and changed my password due to my initial typo for a 2FA token! I suspect at the very least there is a serious flaw in the 2FA setup process. Meanwhile, I’m still locked out of my account, and am highly concerned someone has my data. I’m still waiting on SpiderOak’s tech support, the lag time on replies is incredibly long… My confidence is immensely shaken.