Comment by rst | Hacker News Reader

Comment by rst | Hacker News Reader

Parent Full thread

Title's correct: there is no heartbleed in Tarsnap, because the only thing that was using OpenSSL was using an old, unbugged version.

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...

I don't think he'd refute that he'd have more to worry about had he not been lucky enough to be on an unaffected version of OpenSSL. I believe his point was that the use of stunnel to terminate SSL connections mitigates some of the attack vectors that could've been used to recover customer information in the event of having been compromised at the OpenSSL layer, and that the architecture of Tarsnap itself absolutely precludes recovery of customer backups in any event. And that these facts aren't an accident.

The important takeaway from this post is that it pays to employ layers of security when building software systems.

I was reacting mostly to the apparent exclusion of usernames, passwords, and session cookies (all exposed in net traffic) from the category of "anything sensitive".

Fair point. Perhaps I should have said that the stunnel/jail setup keeps OpenSSL bugs away from the more sensitive things.

If I understand correctly, he's decoupled the SSL connection handling from the http server. That seems to have all kinds of advantages to me, for example if a vulnerability in your SSL library is found you could quickly swap in SSL termination based on another library (e.g. gnutls or nss) or if there was a vulerablity in stunnel you could change it out for stud or even apache or nginx in a jail (assuming you had any or all of these things ready to go). Should also make for more flexibility with load balancing. Brilliant engineering.

Yes. And assume there will be bugs.

"able to steal the SSL certificate, to be sure, and also able to intercept other HTTPS connections"

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.

The worse problem is that once you get the private key you can MITM the traffic or, if forward security was not used, decrypt a sniffed one -- this will limit the casual attacker to a directed attacks, though.

Reply on news.ycombinator.com