[openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

[Hubert Kario via RT]

On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 02:02:36pm +0000, Hubert Kario via RT wrote:
> > On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT 
wrote:
> > > On Fri, Sep 25, 2015 at 01:20:12pm +0000, Hubert Kario via RT 
wrote:
> > > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> > > > branches reject Client Hello messages bigger than 2^14+4 bytes.
> > > 
> > > IIRC SSLv3 does place the limit at 2^14 or so bytes, so I think
> > > the
> > > problem is that OpenSSL only checks for that.
> > 
> > yes, it does place a limit of 2^14, but only on _records_, not
> > handshake messages that travel in those records
> > 
> > > I think a proper fix would be to have all the ssl_get_message()
> > > calls
> > > changed to use the proper "max" parameter depending on the
> > > protocol
> > > version.
> > 
> > As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly
> > the same as in they don't specify any upper size limit for the
> > Handshake protocol messages or Client Hello specifically other than
> > the limits enforced by the length fields themselves.
> > 
> > Remember, the records are completely independent of messages that
> > travel through them, record layer is just there to multiplex the
> > different protocols that are required for TLS to work (handshake,
> > CCS, application data, etc.)
> 
> Right. Some of the handshake messages do have a maximum length though
> (e.g. ChangeCipherSpace), so the maximum length check shouldn't be
> removed (as a sanity check). In the case of ClientHello, the minimal
> fix for the problem then is just a matter of finding the absolute
> maximum it can hold (which may as well be whatever the Handshake
> length field maximum value is).

the protocol states that the message must have all bytes accounted for 
if the implementation supports extensions, so if there is data trailing 
extensions array, its a protocol violation (I'm working on test cases 
for that right now)
 
> As a matter of test I changed the ssl_get_message() in
> ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum size,

it doesn't have in theory, but it does in practice, as extensions can 
only be 2^16 long, same for cipher suites, and you can't have data 
trailing the messages, so the actual size is limited to something closer 
2^18, so if the client hello parser is correct, it will be limited by it

> and the tlsfuzzer failures went from 5 to 2, are all the tests
> supposed to pass? If so, then there's another problem as well.

yes, there are also tests for record layer carrying the data in 1 byte 
chunks. The specification disallows only empty record layer messages.

But it is less severe, as it doesn't cause a de-facto TLS extension 
intolerance.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150925/28bd98c2/attachment.sig>