
OpenBSD disables Heartbeat in libssl, questions IETF - mschuster91
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl/Makefile?rev=1.29;content-type=text%2Fx-cvsweb-markup
======
ctz
This patch is setting OPENSSL_NO_HEARTBEAT, but openssl actually only disables
heartbeats when you set OPENSSL_NO_HEARTBEATS (note trailing S).

Someone should make a thing which does sentiment analysis on commit messages,
and flags vitriolic or angry commits as possibly containing more typos than
usual.

~~~
0x0
That's almost too funny.

Edit: Does that last "ok" line mean that two other committers reviewed and
OK'ed this patch as well? Three openbsd committers approved a one-line change
that didn't fix a single thing? (And people wonder how the OpenSSL bug could
live on for two years =) )

~~~
opendais
It is but we should have a dose of humility in mocking them since many, many
people [including everyone on this site that is a dev] make stupid mistakes
from time to time. Such is the nature of the profession. None of us commit
perfect code the first time, every time.

~~~
0x0
Exactly.

I'll just leave this here.
[http://article.gmane.org/gmane.os.openbsd.misc/211963](http://article.gmane.org/gmane.os.openbsd.misc/211963)

~~~
IgorPartola
Wha-what? That's pretty crazy. At the very least, if OpenSSL goes through this
trouble, why doesn't it just implement its own malloc and friends that are
both fast and secure? In fact, shouldn't it include something like
scurb_and_free() so that sensitive bits would actually be erased when not
needed. That seems like a much better solution than the approach described in
this link.

~~~
dgl
It gets worse, see [http://www.tedunangst.com/flak/post/analysis-of-openssl-
free...](http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-
reuse)

Essentially the code mistakenly relies on the freelist being LIFO and not
being scrubbed.

~~~
TwoBit
Whoever said that OpenSSL was written by monkeys continues to be proven right.

~~~
davidw
That's a fairly rude thing to say. Would you say that to their faces? This is
a pretty large site, and a lot of people stop by here, possibly including some
of the "monkeys" .

By all means, call the code what you want, but separate that from the people.

~~~
pyvpx
something tells me a similar snafu made by a CS student would get "fairly
rude" comments in reply by any competent instructor or advisor.

~~~
bowyakka
you say that and yet I have had to teach people coming from several fairly top
institutions that "no your lecturer was wrong, it is inappropriate to directly
memcpy() from the network into a struct"

------
tptacek
There are smart people working in the TLS WG, but there are also people there
that shouldn't be governing the development of the Internet's most important
encrypted transport.

More importantly, the working group appears to be geared towards saying "yes"
to new features, when exactly the opposite posture is needed. The Heartbeat
feature is just the most obvious example, because its reference implementation
was so slapdash.

The weirder thing here is that it would even be controversial or newsworthy to
disable TCP TLS heartbeats, a feature nobody needs or really ever asked for.
Why was it enabled by default in the first place? What sense did that decision
ever make?

~~~
ecma
Would you please link to this supposedly slapdash reference implementation?
Taking RFC6520 at face value, it seems fairly reasonable and not out of line
with other existing heartbeat protocols.

I've not read as much as I would like on the IETF's involvement in this but as
I read the situation, Theo has just hurled vitriol at them for specifying a
completely reasonable feature that the openSSL team implemented incredibly
poorly.

~~~
tptacek
It's _not_ a completely reasonable feature.

It's a feature that had a sensible use case in DTLS (datagram TLS, TLS not run
over TCP). It's unclear as to whether the use case was best addressed at the
TLS layer, whether it could have been specified as something run alongside
TLS, or whether it was something that applications that cared about path MTU
could have handled for themselves.

The TLS WG actively discussed whether Heartbeat had reasonable use cases in
TCP TLS. Some people agreed, some disagreed. Nobody threatened a temper
tantrum if the feature was added to TCP TLS. Therefore: the extension was
specified for both TCP TLS --- which does not need extra path MTU discovery,
and which already has a (somewhat crappy) keepalive feature --- and DTLS.

The larger problem is in treating TLS like a grab-bag of features for corner-
case applications.

~~~
ecma
Okay, I definitely agree regarding crufty specs. The decision to include
heartbeats could easily have left left it as a variant feature rather than
core spec.

I still don't agree with the OpenSSL implementation being reference spec if
you were refering to that as pygy_ pointed out. Unless the IETF released that
code as an institution, I would consider it the same as any other 3rd party
implementation - ie. not necessarily correct. How am I to know that the RFCs
author wrote it unless I go digging? Why should I trust anything they wrote
which may or may not have gone through any rigorous checking?

This isn't so much directed at you, tptacek (since your pedigree is well
known), as it is the others bashing the IETF for implementation flaws - bash
them for what they actually did and perhaps instead of getting angsty at the
powers that be, try getting involved in projects like this if you believe they
are so important.

------
higherpurpose
I stopped trusting IETF since this:

[http://arstechnica.com/security/2014/01/nsa-employee-will-
co...](http://arstechnica.com/security/2014/01/nsa-employee-will-continue-to-
co-chair-influential-crypto-standards-group/)

When after all the Snowden and RSA revelations they're not willing to get rid
of the putrid influence of NSA inside of IETF, well then...not much trust left
there.

------
necubi
I was confused what RFC 520 ("A Proposed File Access Protocol Specification")
had to do with any of this. It looks like Theo meant to refer to RFC 6520:
[https://tools.ietf.org/html/rfc6520](https://tools.ietf.org/html/rfc6520).

~~~
coverband
Thanks, I was going crazy trying to figure out the connection!

------
TheMagicHorsey
Why does a heartbeat acknowledgement need a variable sized payload embedded in
the reply? Can someone explain this in a way that is accessible to a
programmer without much security experience.

Thanks!

~~~
pwg

      1) You send a heartbeat at time t0;
      2) You wait until time t1;
      3) You send another heartbeat at time t2;
      4) You receive a heartbeat reply at time t3;
    

Was your t3 receipt the result of your t0 heartbeat, or your t2 heartbeat?

That is the purpose of the payload, to distinguish which reply matches with
which transmission.

Now, why variable sized with a max of 64k vs. say an 8-byte integer? The
variable sized with max of 64k was most likely intended to support the second
purpose in the RFC, path MTU discovery. To discover the path MTU, you need to
be able to send a "too big packet", as well as adjust the packet size until
you find the proper MTU value.

[edit, formatting]

~~~
TheMagicHorsey
I understand needing a unique identifier to distinguish between heartbeats ...
but why conflate the heartbeat with Path MTU, which is an orthogonal process.

Is it really that much less efficient to do Path MTU with a different
message/system/module? Why absorb this function into the OpenSSL pacakge?

I feel I am still missing something about the way this system works. Perhaps I
just need to educate myself more on security and networking.

~~~
pwg
> I understand needing a unique identifier to distinguish between heartbeats
> ... but why conflate the heartbeat with Path MTU, which is an orthogonal
> process.

The only people who can accurately answer that are the author of the RFC/code,
and the TLS committee members who discussed the changes.

From a security standpoint, it is more dangerous to commingle the two, because
a bug in one side (path MTU) will also effect the other half (heartbeat). And
that is exactly what happened.

> Why absorb this function into the OpenSSL pacakge?

Unknown. Path MTU discovery is supposed to be handled at a low layer in the
OSI network stack abstraction (closer to the physical hardware) such that
higher level layers/apps should not need to care. Putting it into TLS the
protocol is a blatant layering violation.

------
jethro_tell
Maybe OT, but are the OpenSSL project and OpenBSD project related in any way?
For some reason I was thinking it was like the OpenSSH project.

~~~
rubiquity
No, they aren't related at all. OpenSSH is everyone's poster child for a good,
open implementation of a security protocol.

~~~
SixSigma
For some values of "everyone"

Rob Pike Responds - Slashdot

18 Oct 2004 ... ... but when ssh is the foundation of your security
architecture, you know things aren't working as they should

[http://slashdot.org/story/50858](http://slashdot.org/story/50858)

~~~
scott_karana
I don't think he was impugning SSH's _security record_ at all: just the
perceived abuse of the protocol.

The entire quote, in context:

 _10) Biggest problem with Unix - by akaina

Recently on the Google Labs Aptitude Test there was a question: "What's broken
with Unix? How would you fix it?"

What would you have put?

Pike:

Ken Thompson and I started Plan 9 as an answer to that question. The major
things we saw wrong with Unix when we started talking about what would become
Plan 9, back around 1985, all stemmed from the appearance of a network. As a
stand-alone system, Unix was pretty good. But when you networked Unix machines
together, you got a network of stand-alone systems instead of a seamless,
integrated networked system. Instead of one big file system, one user
community, one secure setup uniting your network of machines, you had a
hodgepodge of workarounds to Unix's fundamental design decision that each
machine is self-sufficient.

Nothing's really changed today. The workarounds have become smoother and some
of the things we can do with networks of Unix machines are pretty impressive,
but when ssh is the foundation of your security architecture, you know things
aren't working as they should._

~~~
SixSigma
He just didn't say so in that interview, however :

From: 9fans@cse.psu.edu (rob pike)

Date: Mon, 1 Jan 2001 09:37:12 -0500

Subject: [9fans] Re: The problem with SSH2

Message-ID: <20010101143731.DB61F199E7@mail.cse.psu.edu>

My disagreement with SSH is more specific. It is a securitymonger's plaything,
so has been stuffed with every authentication and encryption technology known,
yet those that are configured when it is installed is a random variable.
Therefore both sides must negotiate like crazy to figure how to talk, and one
often finds that there is no shared language. This is idiocy. The complexity
is silly, but much worse is that there isn't at least one guaranteed protocol
for authentication and encryption that both ends always have and can use as a
fallback. I would argue that that would always be sufficient, but I know I'm
in the minority there. I do argue that it's demonstrably necessary.

Algorithms everywhere, and not a byte to send.

By making the thing too complicated, they defeat the very purpose of security.
Difficult administration results in incorrect or inadequate installation.
There are cases when I can't use ssh, a direct consequence.

-rob

Russ Cox chimes in

we're stuck with ssh, but let's not delude ourselves into thinking it's a good
protocol.

(i'm talking about ssh1; ssh2 looks worse.)

russ

~~~
scott_karana
Thanks, that makes more sense.

------
bcoates
This strikes me as 100% backwards, isn't the entire point of the IETF RFC
process to memorialize existing practice, not be a design studio for new
protocols? Wasn't it followed here (RFC6520 existing to document the OpenSSL
implementation of heartbeat)?

If the IETF is the only thing standing between us and any jackass introducing
vulnerabilities into everyone's network stack we're in bigger trouble than I
thought.

~~~
ahomescu1
RFC stands for "Request For Comments", which I always thought meant new stuff
up for peer review. Wikipedia also describes them as:

 _An RFC is authored by engineers and computer scientists in the form of a
memorandum describing methods, behaviours, research, or innovations applicable
to the working of the Internet and Internet-connected systems. It is submitted
either for peer review or simply to convey new concepts, information, or
(occasionally) engineering humour. The IETF adopts some of the proposals
published as RFCs as Internet standards._

------
mcosta
Is the IETF the implementors of OpenSSL? If not, this is pure crazy. The
heartbeat feature seems useful to me. I mean, keep alive at TCP level leaks
information. Even when this information is that there is no transmission.
Transmitting a heartbeat tells the other side is alive and is not
distinguishable from normal traffic to a passive attacker.

~~~
sp332
Heartbeats are used for UDP and other connectionless protocols. TCP doesn't
need heartbeats to tell if the connection went down.

~~~
0x0
I think it can be useful when the TCP connection is going through NAT which
may drop the rule and stop passing packets after idling, no?

~~~
carey
In retrospect, I think using TCP_KEEPALIVE would be a better solution to this
specific use case. Are TLS heartbeats truly indistinguishable from normal
traffic?

~~~
pstrateman
TCP Keepalive is a much better solution for this problem.

Nearly all bitcoin pools utilize TCP keepalive to maintain connections with
miners.

These are systems in which performance and DoS resistance are paramount.

------
meshko
Is there any argument in defense of the TLS heartbeat extension? It seems
completely inappropriate thing to stick into TLS (wrong level of abstraction),
and the idea of sending any kind of payload as part of heartbeat seems
completely redundant (what does this achieve over just basic fields "this is
heartbeen #17" \-- "this is response to heartbeat #17"?

------
hf
The commit message contains a rather succinct, albeit drastic description-cum-
definition of Heartbleed:

> [A] 64K Covert Channel in a critical protocol.

------
meetavc
How can we get developers to keep it simple, and stop introducing new
"features"? [This applies to OPENSSL as well as most software out there that
has a new "release" all the time]

------
robobro
Sharp guy.

------
codewiz
Oh, and they're using CVS because it's so secure!

------
colinbartlett
CVS is still in use by anyone?

~~~
taylorbuley
Feigned surprise! I read about this today!

~~~
colinbartlett
Certainly wasn't feigned, though I understand your reference. Absolutely no
offense meant.

I'm genuinely surprised. Just as I would also be surprised if Windows 3.1 or
magnetic tapes or punch cards were still in use. I thought these technologies
were supplanted long ago.

~~~
kjs3
CVS is in use _many_ places, especially in decades old source trees where
migration would result in the loss of to much metadata or to much build
automation is dependent on CVS. I personally know of several instances of
this.

Windows 3.1? I run into it occasionally in places like manufacturing where
upgrade cycles are decades long (was recently at a client who's most critical
machine was built in 1905). FWIW, DOS can still be found everywhere.

Magnetic tape? Really? LTO-6 is up to 2.5TB uncompressed and LTO-7 is
imminent.

Punch cards? See: Scantron.

Just because there's a cool new replacement for something, doesn't mean you
should jump on it, or that the old tech is now worthless.

