TL;DR: Jidoteki was NOT affected by the Heartbleed vulnerability.
A few days ago, we were notified about an extremely serious flaw in the most recent versions of the OpenSSL library. The details are described in CVE-2014-0160.
Since we control 100% of our server infrastructure, most of our servers were unaffected by this bug.
“Who owns your security?” - http://whoownsyoursecurity.com/
Jidoteki
For Jidoteki, our infrastructure’s servers were all using a slightly older (yet updated) version of the OpenSSL library. This version was not affected by the Heartbleed bug.
VPN
We use IPsec with NTRU encryption for VPN access to the servers, and to encrypt communications between servers. Fortunately because we don’t use OpenVPN (which relies on OpenSSL), our VPN was also unaffected.
Unscramble
Our internal servers, which we use for our own private stuff (bugs database, monitoring, log & stats dashboards), were running newer systems with the affected version of OpenSSL.
We patched those and re-compiled all our custom binaries. This was rather quick and easy because we use Ansible to manage those servers.
Luckily, nobody except Unscramble staff have access to our internal servers.
Cloud services
Due to the nature of our business (helping companies use SaaS services on-premises, we don’t use those providers for private business data (eg: Dropbox, AWS).
It would be ironic if we did. Hah!
SSL Certificates
We’ve replaced our old SSL certificate with a paid wildcard from RapidSSL. We’re currently using Startcom’s StartSSL free certificates for jidoteki.com, Startcom StartSSL are following extremely unethical business practices in regards to this security flaw, by charging customers to revoke their potentially leaked private SSL keys.
Fortunately we didn’t need to revoke that SSL certificate, because the server wasn’t vulnerable, but we plan to never use Startcom’s services EVER AGAIN. I encourage everyone else to avoid that company, like the plague. They are the definition of evil and are not as security conscious as we originally thought.
In fact, I recommend you disable the Startcom CA from your browser and computer’s trusted certificates list.
What else should you do?
If you’ve already distributed a vulnerable virtual appliance to your customers, you’ll need to create an update_package which contains newer OpenSSL libraries, and which restarts services that rely on those shared libraries. If you have custom-compiled binaries, you’ll also need to include those in the update_package.
If you’ve signed up to any SaaS services which have had compromised SSL certificates, you should change your passwords and ask them for an on-premises version. If they don’t have one, please direct them to us ;)
Moving forward
We’ll write another post on how to handle this bug in an offline virtual appliance.
In the meantime, feel free to contact us if you need help handling this bug. We’re also available in #Jidoteki on Freenode IRC.
Also don’t forget to signup for early access to Jidoteki. We’re getting really close to releasing it, and I’m sure you will love it!