Tarsnap: No heartbleed here
daemonology.net
daemonology.net
That said, he goes on to claim that even if he had been using a buggy SSL stack, his stunnel setup "keeps the bug away from anything sensitive." But his prior blogpost on the stunnel setup[1] itself acknowledges some limits: "if someone compromises OpenSSL, they will still be ... able to steal the SSL certificate, to be sure, and also able to intercept other HTTPS connections". Meaning, I think, they'd have access to the net traffic in cleartext --- including such goodies as usernames and passwords, which might be shared with other sites.
(Colin might respond, "use a password manager". He very likely does. Most likely, though, a lot of his clients don't.)
So, if they (well, he) had been running a vulnerable OpenSSL, he might still have things to worry about.
[1] http://www.daemonology.net/blog/2009-09-28-securing-https.ht...
The important takeaway from this post is that it pays to employ layers of security when building software systems.
Couldn't a SSL-terminating process that's vulnerable to heartbleed also leak unencrypted traffic? The attacker wouldn't even need to be in a position to intercept other users' connections, which is much worse.
I don't know about stunnel specifically though, maybe it doesn't free memory containing unencrypted traffic.
Security is one of those notoriously hard fields to get right for precisely this reason: you don't know you're doing a bad job until it's too late.
I'm starting to get frustrated by the security experts basically chasing everyone away from cryptography. Am I the only one getting tired of the experts (many with misaligned incentives) telling us, "This stuff is really hard... Just trust us"?
In security, you have a cabal of self-appointed experts who write inscrutable code and chastise you if you try to improve on it. What does that accomplish other than chasing people away?
These security experts make their livelihoods based on their credentials; they have every incentive to keep others out. At what point do we stop giving them the benefit of the doubt and start educating ourselves? Trust can only go so far.
I think it's more a case of the subject being so important that it's not really something that you can take shortcuts with. When it's something so critical to daily life as the internet is becoming, it's imperative that all code made for security purposes is carefully considered, and architected to avoid the tiniest bugs. Hobbyists or amateurs (myself included) are not necessarily qualified to judge what might constitute a critical bug, and that is one of the reasons the barrier to entry in the field is so much higher.
I agree wholeheartedly, but all you have to do is take a look at these security libraries' code, processes, and recent bugs to realize that the experts are failing at this. Their math and theory may be flawless, but their code is shit.
I think cryptography could benefit greatly from an influx of software engineering. We should be using modern testing and code review practices to bring some measure of reliability and architectural clarity to cryptographic work. The attitude toward programmers who aren't experts (yet!) doesn't exactly encourage this.
I don't think it is any harder, actually. It's just that the stakes are much higher.
A lot of crypto is unintuitive.
And the goal-posts keep moving. You have to keep well-read and very objective.
You can say this about mainstream programming, but its a bit of a stretch. There is plenty of mainstream programming using the equiv to bubble sorts and nobody should care. You can get away with being a bad programmer.
Because the risks are higher, and you can't get away with being mediocre, is why crypto is hard.
PS: not a tarsnap user, but love your work and your thoughtful posts :)
Actually, there's a school of thought that this is exactly how bridges are assessed. Henry Petroski's To Engineer is Human argues that structural engineers never have have successful structures. They only have the current absence of failure.
I reviewed it here: http://chester.id.au/2013/07/07/review-to-engineer-is-human-...
Why was Tarsnap running a version of OpenSSL that's at least two years old^1 ? My understanding is that, while you might not want to upgrade immediately upon release (because there may be new bugs), neither should you never upgrade (because releases fix old bugs).
Is it because the website itself doesn't do much -- it's not the business; backup is -- so not much time is put into it?
[1] OpenSSL 1.0.1, the first version of OpenSSL with the bug, was released in March 2012: http://heartbleed.com/
It's a risky thing to do if you're not willing to own those judgement calls; I wouldn't recommend that most shops do that. Among other things, you need to eyeball the diffs.
What you do miss out on is new protocol support, which for TLS can be a huge problem when secure and compatible crypto options run out.
(Sadly, people will usually err on the side of compatibility, which in the past boils down to the terrible RC4)
Some of these distros are LTS, so the bug fixes are usually back ported. The latest 0.9.8 is y which is from Feburary 2013.
Upgrading OpenSSL introduces other problems though -- the OpenSSL developers don't seem to understand the concept of a "stable branch" or "binary compatibility", so importing a new version of OpenSSL can mean that everything which links against it has to be recompiled. This is one of the reasons why FreeBSD doesn't get major OpenSSL updates on stable branches -- our policy is that if a binary worked on X.0, you should be able to run it on all future X.* releases.
[1] http://www.daemonology.net/blog/2014-04-09-tarsnap-no-heartb...
https://news.ycombinator.com/item?id=7523953https://news.yco...
Although in Tarsnap's case, an SSL leak wouldn't be terrible because everything's encrypted before even going over the wire, at least to my understanding.
Yes, this is one of my standard recommendations: If you can, distribute your own damn keys.
in Tarsnap's case, an SSL leak wouldn't be terrible because everything's encrypted before even going over the wire
Correct, and requests are authenticated using signatures, so even if Tarsnap was using SSL, there would be no tokens disclosed which could be stolen. Breaking Tarsnap's client-server encryption/authentication would allow an attacker to identify the names of blocks of data, though -- so he could see e.g., that someone is deleting today the data which was uploaded yesterday.
I like to have the ability to view my SSL traffic in plain text.
Should the user be able to see what her computer is sending out? I think she should. And encrypted traffic should not be some special exception.
Installing someone else's "MITM" software to decrypt SSL seems unnecessary.
It is much simpler to generate and install your own "fake" certificates that you control.
stunnel is one option.
There are others. socat, Pound, etc.
It should be the user who has the final decision over which certificates to trust. Users are the real "Certificate Authorities". They should have full control over encryption and decryption should they want to exercise it.
Is it wise to irrevocably delegate the decision to trust/not trust to website owners and browser authors? Perhaps those promoting solutions like "TACK" should give this more thought.
And they do.
I'm not sure what you're getting at here. You and I and my mother all have the ability to edit the root CA certificates on our computers and add our own, if we wish.
But I'm seeing more and more authentication information being incorporated ("baked in", pre-installed, whatever) into browsers, whether it is lists of "valid" TLD's, certificates for "approved" CA's, or chosen individual website certificates.
Personally, I think this information should be cleanly separated from the software that may use it rather than pre-installed and "hidden from the user".