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

[Hubert Kario via RT]

On Friday 25 September 2015 16:33:40 Matt Caswell wrote:
> On 25/09/15 14:19, Hubert Kario 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.
> 
> Right. The reason for that is that there is an explicit (deliberate)
> check for it. Each message in its call to ssl_get_message specifies
> the max size. For ClientHello:
> 
>     n = s->method->ssl_get_message(s,
>                                    SSL3_ST_SR_CLNT_HELLO_B,
>                                    SSL3_ST_SR_CLNT_HELLO_C,
>                                    SSL3_MT_CLIENT_HELLO,
>                                    SSL3_RT_MAX_PLAIN_LENGTH, &ok);
> 
> The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH
> (=16384, or the max possible size that can fit into a single record).

well, except that this doesn't include the message type and message 
length fields, so the message (from the point of view of record layer) 
is actually 2^14+4 bytes so it won't fit into a single record :)

the actual maximum size is:

 4 + # handshake protocol header
 2 + # client_version
 32 + # only valid length for random
 1 + # length of session_id
 32 + # maximum size for session_id
 2 + # length of cipher suites
 2^16-2 + # maximum length of cipher suites array
 1 + # length of compression_methods
 2^8-1 + # maximum length of compression methods
 2 + # length of extensions
 2^16-1 # maximum length of extensions
= 131400 or 131396 without header

> Every message has one of these defined. Some of them are quite
> arbitrary values.
> 
> E.g. for ServerHello
>     n = s->method->ssl_get_message(s,
>                                    SSL3_ST_CR_SRVR_HELLO_A,
>                                    SSL3_ST_CR_SRVR_HELLO_B, -1, 20000,
> &ok);
> 
> Why 20000? No idea.
> 
> The same restriction exists in the state-machine-rewrite branches
> because I'm ultra-cautious.

entirely understandable

> I am reluctant to remove an explicit check
> like that without understanding why it's there in the first place.
> Especially if its not breaking anything. Are we ever likely to
> encounter a ClientHello > 16384 bytes?

with actual TLSv1.2? likely "nothing" and "never".

But the same could have been said about version number not being 
anything but 3.0 or 3.1 when TLSv1.0 was published, and we all know how 
well this turned out to be...

Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends 
up as an extension, possibly multiple ones), and that quantum computing 
resistant algorithms usually require fairly large key sizes (large 
enough that protocol limitations itself are problematic), we may see 
Client Hellos larger than 16k in not so far future.

-- 
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/0a8fbf8c/attachment.sig>
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod