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
signature.asc
Description: PGP signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
