I think that I found the answer for my question on the RFCs 6520 on page 5 (
https://tools.ietf.org/html/rfc6520#page-5) and 6066 page 8 (
https://tools.ietf.org/html/rfc6066#page-8).
Take a look on the RFC6520 on page 5:
The total length of a HeartbeatMessage MUST NOT exceed 2^14 or
max_fragment_length when negotiated as defined in [RFC6066].
Now let's take a look on RFC6066 page 8:
Without this extension, TLS specifies a fixed maximum plaintext
fragment length of 2^14 bytes. It may be desirable for constrained clients
to negotiate a smaller maximum fragment length due to memory limitations or
bandwidth limitations.
I think the idea to have the client setting a SMALLER length is just for in
case of memory or bandwidth limits.
I had this in my mind because if there wasn't a reasonable explanation for
the client set the length it could be that the developer malicious
intention to include this bug. Anyway, I was thinking wrong since we have
the reason on the RFCs.
Thanks
Ricardo Iramar
On Fri, Apr 11, 2014 at 12:09 AM, Ricardo Iramar dos Santos <
rira...@gmail.com> wrote:
> Reading this post
> http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.htmlit's
> saying "This is the length indicated by the SSL client for the
> heartbeat payload".
> Why the client should set the length of a payload? Why not have a fix or
> some values? Sorry but I'm a not C developer and I didn't get the idea of
> this.
>
> "Finally (and here's the critical part), using the size supplied by the
> attacker rather than its actual length, it copies the request payload bytes
> to the response buffer."
>
>
> On Thu, Apr 10, 2014 at 9:17 PM, Michal Zalewski <lcam...@coredump.cx>wrote:
>
>> >
>> http://m.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html
>>
>> "Man who introduced serious 'Heartbleed' security flaw denies he
>> inserted it deliberately"
>>
>> Wow, we're climbing to some new levels here.
>>
>> /mz
>>
>> _______________________________________________
>> Sent through the Full Disclosure mailing list
>> http://nmap.org/mailman/listinfo/fulldisclosure
>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>
>
>
_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
