Tarsnap: No heartbleed here
By now I assume everyone is aware of the "Heartbleed" bug in OpenSSL. I wasn't planning on commenting on this, but considering how many emails I've received about this I've decided that I need to make a public statement: Tarsnap is not affected by this vulnerability.There's a few reasons for this. First, the Tarsnap client-server protocol does not use TLS; instead, it uses a protocol which is about 100x simpler (in terms of the number of pages of documentation required to define it). This means there's less code and far fewer edge cases where bugs can lurk without being triggered on a regular basis. The most secure code in the world is code which is never written; the least secure code is code which is written in order to comply with a requirement on page 70 of a 100-page standard, but never gets tested because nobody enables that option.
So the Tarsnap service is completely unaffected; what about the Tarsnap website, where SSL/TLS is used? There's nothing very sensitive accessible from the Tarsnap website — unlike other backup services, knowing someone's account password will not allow you to access their data — but if you managed to steal cryptographic keys used by the website you could see how much data someone had stored or create an account without performing the "receive a confirmation email and click on a link" handshake. But this is exactly why, almost five years ago, I wrote about securing an HTTPS server by terminating SSL connections with stunnel: In the event of vulnerabilities in the SSL stack, this keeps the bug away from anything sensitive.
Mind you, I was also lucky: The Tarsnap webserver happens to be running an older version of OpenSSL which never had the vulnerable code, so in this case I could have done without any exploit-mitigation techniques. But luck is a fickle mistress; I don't expect to have her on my side the next time a critical vulnerability is found in OpenSSL.
As I commented a few years ago, we don't assess the structure of bridges by asking "has it collapsed yet?", and we shouldn't assess the security of software by asking "can we find any security flaws in it?". Continuing the metaphor, a good engineer designing a bridge won't assume that it will always be in perfect condition; she will design it with enough redundancy that even if a truck damages support struts the undamaged portions of the bridge structure will suffice to ensure that the bridge does not collapse. In software security, this means relying on multiple layers of security: Start by assuming that some of them will be compromised, and design your system to ensure that your entire system does not collapse as a result.
We know how to do this. All it takes is some care and attention.