[pro] Heartbleed?

[Max Rottenkolber]

On Wed, 23 Apr 2014 20:39:48 +0200, Pascal J. Bourguignon wrote:
>    When a HeartbeatRequest message is received and sending a
>    HeartbeatResponse is not prohibited as described elsewhere in this
>    document, the receiver MUST send a corresponding HeartbeatResponse
>    message carrying AN EXACT COPY OF THE PAYLOAD of the received
>    HeartbeatRequest.

I didn't mean to dispute that CL is a safer language. My point is that, as
an implementer, the above paragraph in an SSL protocol extension should
raise red lights.

What is the function of the described behavior? Why would I want to echo
back data in context of a keep alive?
A: None. You don't want to do that.

My position on this is to refuse to implement it. If that means my
implementation is useless in the context of other implementations, I need
to implement a better standard. I'd go as far as saying this is a moral
issue. When implementing a standard means building a weapon pointed at
half the Internet, the implementer is responsible for the resulting
threat.

I have made mixed experiences with this. So far I have implemented a few
standards where this approach worked just fine (email client, web server).
I could just omit the behavior I deemed unacceptable and refuse to handle
those messages or send a "501 Not Implemented" respectively. And while
both email and the HTTP standards bear tons of legacy baggage and can be
tedious to implement, I refer to them as _good_ standards bodies, because
they let you safely omit their questionable components.

A security guy reading the TLS standard on the other hand, WILL think that
it was written by a malicious party, optimized for being impossible to
implement in a safe way. And while it is easier to implement the TLS
standard correctly in Lisp, I believe it should be simple and well-
written enough to be able to implement it safely even in C.