Tarsnap: No heartbleed hereBy 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.
Tarsnap price cutOn Tuesday of last week, Google cut prices for their Google Cloud Platform services. Not to be outdone, less than 24 hours later, Amazon responded by cutting prices on several Amazon Web Services offerings, including the Simple Storage Service where Tarsnap stores customer data. Now it's my turn: Effective April 1st (I nearly announced this yesterday, but decided to wait until the April Fools' jokes were out of the way) I'm cutting Tarsnap's bandwidth and monthly storage pricing from $0.30/GB to $0.25/GB.
This will no doubt annoy my friends Patrick McKenzie and Thomas Ptacek, who for years have been telling me that I should raise Tarsnap's prices. But while Thomas accuses me of running Tarsnap like a public utility rather than a business, and thinks this is a characteristic to be avoided, I see this as a high compliment — and so like a good public utility would, I looked at Tarsnap's revenue and expenses (not just the per-GB costs Tarsnap pays for S3 storage, but also S3 per-request fees, EC2 instances, bandwidth, payment processing costs, and what I consider to be a reasonable salary to pay for the time I spend on Tarsnap), realized that I didn't need Amazon's price cut, and decided to pass it on to Tarsnap users.
Does this mean I will always pass on any future Amazon price cuts? I'm not going to make any promises; Tarsnap's operating costs may go up (if I decide to hire someone, for example). Conversely, as Tarsnap grows I may be able to cut prices further, thanks to overhead costs being amortized over more Tarsnap usage, even without any further price cuts from Amazon (and considering how large these recent price cuts were, I'm not expecting to see any more from Amazon in the near future). All I'm saying is that right now I don't feel any need to increase Tarsnap's profit margins, and rather than pocketing money I don't need, it only seems fair to pass this unexpected windfall on.
I hope Tarsnap users will appreciate the savings — but if not, I'm just an email away: I can always sign people up for a special Patrick McKenzie surcharge.