[langsec-discuss] cross-posting a bit on Heartbleed

lee hughes toxicnaan at gmail.com
Thu May 1 03:03:05 UTC 2014


Isn't this a classic example of a protocol begin to powerful? Should a
client to server protocol be even able to set buffer sizes etc etc.

would a better solution would to simplify the protocol and in the spec use
buffers of a predetermied size and ignore client requests to read 'an
amount of memory' altogether. I can see why this feature was implemented,
but is it *really* that necessary?

i.e.

Client -> Send me a keep alive (please)
Server -> i currently have x amount bytes. here it is. you deal with it.

Client -> I have some data coming in, i better allocate enough memory for
it , however the spec says i'll never get more x bytes. so if i read more
than this, something very bad had occured.

The spec now deals with hard limits, rather than the protocol requesting
those limits and hoping that the implementer will deal with those  limits,
especially when those limits are being abused by a untrusted connection!

The client loses the ability to set the size of the data returned, however,
does it really need that 'power' in the first place?

Looking at our own product, it focuses on buffer overflows when WRITING to
a buffer, however it's not tuned for  READING from a buffer, or in fact
over reading. Should the protocol be negotiating sizes of 'things'  at all,
if running over tcp?

If I'm sending  lots of data, tcp should be able to fragment it and deliver
it correctly, however I've got a feeling the protocol was designed to
accommodate udp transports, so it's case of re-inventing the wheel, and
reinventing all the nasty buffer bugs that occurred with non-tcp
connections (icmp ping of death to name a few)

However, i don't think this was a case of the spec being hard to
understand, as the spec and implementation was written by the same person
;-).

Interesting stuff.

Lee!


On Sat, Apr 12, 2014 at 6:44 PM, Daira Hopwood <daira at jacaranda.org> wrote:

> On 11/04/14 16:40, William Sargent wrote:
> >> Actually the protocol *did* specify that:
> >>
> >> https://tools.ietf.org/html/rfc6520#section-4
> >>
> >> #   If the payload_length of a received HeartbeatMessage is too large,
> >> #   the received HeartbeatMessage MUST be discarded silently.
> >
> > There is a formally verified version of TLS, miTLS.  I’d be curious to
> see how it measures
> > up against the attack tools.
> >
> > http://www.mitls.org/wsgi
>
> miTLS does not support the heartbeat extension, and so is not vulnerable.
> (The only extension it supports is renegotiation_info.)
>
> --
> Daira Hopwood ⚥
>
>
> _______________________________________________
> langsec-discuss mailing list
> langsec-discuss at mail.langsec.org
> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20140501/f7ebf343/attachment.html>


More information about the langsec-discuss mailing list