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 <da...@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@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss > >
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
