
Tarsnap: No heartbleed here - cperciva
http://www.daemonology.net/blog/2014-04-09-tarsnap-no-heartbleed-here.html
======
rst
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...](http://www.daemonology.net/blog/2009-09-28-securing-https.html)

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

~~~
rst
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".

~~~
cperciva
Fair point. Perhaps I should have said that the stunnel/jail setup keeps
OpenSSL bugs away from the _more sensitive_ things.

------
casca
For anyone else interested in the protocols that tarsnap uses -
[https://www.tarsnap.com/crypto.html](https://www.tarsnap.com/crypto.html)

------
Oculus
I read the blog post earlier and this one line really resonated with me: _we
don 't assess the structure of bridges by asking "has it collapsed yet?"_

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.

~~~
BrandonM
I like that. I think by that measure, though, OpenSSL is failing badly. It's
like an old rusted-metal and rotten-wood bridge that should have a sign
saying, "No vehicles over 2 tons," but instead it's carrying highway traffic.

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"?

~~~
001spartan
The fact remains that crypto _is_ very hard. I don't see why telling people
that equates to "chasing people away" from cryptography. It would be even more
dangerous to not mention that fact when people try to roll their own
encryption systems. It's just not something that can be safely done by a
hobbyist/amateur, at least not for critical applications.

~~~
cperciva
_The fact remains that crypto _is_ very hard._

I don't think it is any harder, actually. It's just that the stakes are much
higher.

~~~
willvarfar
You say its no harder, but the risks are 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 :)

~~~
cperciva
People using bad algorithms is exactly the sort of thing I was thinking of.
People write horribly broken code in every context; but instead of a bug
making software slower than it should be, when an "equally dumb" bug happens
in crypto code it probably reveals your keys.

------
zck
I'm no security expert, so this is an honest question.

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/](http://heartbleed.com/)

~~~
tptacek
OpenSSL frequently hosts vulnerabilities that don't affect all users of TLS.
If you pay attention to the updates (as Colin surely does), you can filter
down to the updates that matter.

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.

~~~
X-Istence
Or he is running an older version of FreeBSD that contains an older version of
OpenSSL in the base.

~~~
tptacek
For what it's worth: he's the former FreeBSD security officer, so I wouldn't
worry too much about which version of FreeBSD he's using.

------
atmosx
I think the juice is in the comments[1].

[1] [http://www.daemonology.net/blog/2014-04-09-tarsnap-no-
heartb...](http://www.daemonology.net/blog/2014-04-09-tarsnap-no-heartbleed-
here.html#comment-1327391638)

~~~
pseut
And, just to go back to patio11's article[1] "replace OpenSSL for free" is
something that Tarsnap could afford to do as a company, and might make
business sense, if it were substantially more profitable. </nag>

[https://news.ycombinator.com/item?id=7523953https://news.yco...](https://news.ycombinator.com/item?id=7523953https://news.ycombinator.com/item?id=7523953)

------
soundsop
The older posting that is mentioned, which is called Securing an HTTPS Server
is a good read: [http://www.daemonology.net/blog/2009-09-28-securing-
https.ht...](http://www.daemonology.net/blog/2009-09-28-securing-https.html)

------
orthecreedence
This is a plus to distributing your own app...you can just bundle the public
key(s) for your servers with the app and then there's never any reason to
verify through CAs or any such nonsense.

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.

~~~
cperciva
_This is a plus to distributing your own app...you can just bundle the public
key(s) for your servers with the app_

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.

------
yp_master
I prefer SSL termination on the _client-side_ (my computer, my data only).

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.

~~~
jlgaddis
_> 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._

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.

~~~
yp_master
Indeed, that has been my solution.

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

------
tedchs
Does Heartbleed affect OpenSSH? I seem to recall it uses OpenSSL but I haven't
seen it mentioned.

~~~
twic
No. SSH is a completely different protocol to TLS/SSL:

[http://tools.ietf.org/html/rfc4253](http://tools.ietf.org/html/rfc4253)

