What I am doing about “heartbleed”
Well, I’m not actually doing much other than being alert. In this post, I’ll go through my decision process, and hope that is a useful guide to others.
What is “heartbleed”?
“Heartbleed” is the name being given to a bug discovered in the openssl code. Its name comes from the bug being in the heartbeat code, the code that keeps ssl connections alive. A recently discovered bug allows attackers to access server memory, leaving no trace of their activity. Bruce Schneier calls it catastrophic, and that assessment is probably correct.
My first step was to assess my risk. And my next step was to apply the update available from opensuse. I used Yast online update for that, though using “zypper” at the command line, or using the update applet for your desktop should do just as well. Normally, I do updates on Mondays and Fridays, just before I boot to Windows to allow it (Windows) to update its anti-virus tables. Although I assessed my own risk as low, I decided it was worth an extra update check and reboot. I rebooted after the update, so that running software would all be using the updated version of the libraries.
What servers am I running?
The first step in risk assessment is to look at the network services offered on your system. At present, the only servers I run that might be relevant are “sendmail”, “samba” and “sshd”.
For both “sendmail” and “samba”, I determined that the risk is low. And that is because those servers are accessible only from the home LAN. I have not configured my home router to port-forward any of the ports that they use, and at present my router does not support IPv6 (where port-forwarding would not be needed). So, in order for an attacker to access my ssl servers, it would first have to break into some computer on the home LAN.
For “sshd”, there does not seem to be any risk at all. While “sshd” is linked against the “libcrypto” library (part of openssl), it does not use the “libssl” library. So “sshd” is using only the crypto algorithms, and not the SSL/TLS support protocols. So it should not be at risk.
What to do about servers?
In the past, I have been managing a web server (using apache) and sendmail servers at work. If I were still managing those, they would be a concern.
The biggest concern for a server, is with the server certificate. The server has a copy of its private key in memory, and an attacker might potentially get hold of that. On the other hand, the CA certificate used to sign (or certify) the server should be safe. The server does not have the private key for the CA certificate.
If I were still running such servers, my first step would be to replace the server key. Note that this assumes that the software has already been updated so that the bug is not present. There’s no point in updating the server certificate, if the bug is still there and attackers can just as easily get hold of the new replacement private key.
So, step 1 — apply software updates to remove the bug. Step 2 — replace all server certificates. If you purchase server certificates, this might take time. It would also be a good idea to revoke the old server certificates.
What else is at risk?
The main other concern that I am aware of, is with user passwords. If I were running SSL servers, I would be advising users of those servers to change their passwords. Note that it is the passwords transmitted via SSL sessions that are of concern here.
And what about my own passwords? At present, all I am doing is staying alert. If a site advises me to change my password for that site, I will do so. Otherwise I will do nothing.
The passwords of greatest concern are those used for banking and similar services. As far as I know, most banks use commercial ssl software, rather than open source software. So most are probably not vulnerable to this particular bug. Commercial software is just as likely to have bugs as open source software. But they are likely to be different bugs.
Some of the sites that I use may indeed be using open source software. But there is no point in my changing password if they have not fixed the vulnerability. So it is important to wait until advised.
I’m fortunate to not have any serious vulnerability problems on my systems. But I do need to keep alert for the possibility that some of my Internet passwords could have been compromised.