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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
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.

RFC 5246 specifies maximum size of just the extensions field to be
2^16-1:

      struct {
          ProtocolVersion client_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suites<2..2^16-2>;
          CompressionMethod compression_methods<1..2^8-1>;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ClientHello;

reproducer:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\
-nodes -batch
~/dev/openssl/apps/openssl s_server -key localhost.key -cert\
localhost.crt -www

pip install --pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git

cd tlsfuzzer
PYTHONPATH=. python scripts/test-record-layer-fragmentation.py
--
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

_______________________________________________
openssl-bugs-mod mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
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.

AFAICT both SSLv3 and TLS implementations share the same ssl_accept() method
(that is ssl3_accept()), which calls e.g. ssl3_get_client_key_exchange() which
in turn calls the ssl_get_message() method (implemented by ssl3_get_message())
using SSL3_RT_MAX_PLAIN_LENGTH as maximum size.

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.

The above applies to current master, I haven't checked the state machine
rewrite branch yet.

I can look into preparing a patch, if no one beats me to it.

Cheers


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
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.)

--
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

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
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).

As a matter of test I changed the ssl_get_message() in ssl3_get_client_hello()
to use 0xFFFFFF (uint24 max) as maximum size, 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.

Cheers


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz 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

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote:
> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
> > 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

Yeah, but OpenSSL first tries to "get" the handshake body and its length before
parsing it (this is done by ssl3_get_message()). So the "max" argument is
intended to be used, I imagine, as a sanity check: if the message exceeds that,
then it's obviously broken and an "illegal parameters" alert is sent. This is
done regardless of the message type, so the ClientHello parser has to do this
as well.

This max length check is not exactly smart (e.g. the max size of the SSLv3
ClientHello is very different from that of TLS) and could probably be removed
completely, but I don't really know what the consequences of this would be. So
the best next fix would simply be to provide an approximation of an absolute
maximum length for the ClientHello (or just use 0xFFFFFF). I opened a pull
request [0] with just this minimal fix. Anyone is very welcome to propose a
better fix for this though.

How trailing data is then handled is orthogonal to this problem (the length
check doesn't really affect this). It might be that OpenSSL handles it
correctly or not, I don't really know (and having the tlsfuzzer test for this
will be very useful).

Cheers

[0] https://github.com/openssl/openssl/pull/413


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Matt Caswell-2


On 25/09/15 17:05, Alessandro Ghedini via RT wrote:

> On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote:
>> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
>>> 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
>
> Yeah, but OpenSSL first tries to "get" the handshake body and its length before
> parsing it (this is done by ssl3_get_message()). So the "max" argument is
> intended to be used, I imagine, as a sanity check: if the message exceeds that,
> then it's obviously broken and an "illegal parameters" alert is sent. This is
> done regardless of the message type, so the ClientHello parser has to do this
> as well.
>
> This max length check is not exactly smart (e.g. the max size of the SSLv3
> ClientHello is very different from that of TLS) and could probably be removed
> completely, but I don't really know what the consequences of this would be. So
> the best next fix would simply be to provide an approximation of an absolute
> maximum length for the ClientHello (or just use 0xFFFFFF). I opened a pull
> request [0] with just this minimal fix. Anyone is very welcome to propose a
> better fix for this though.

0xffffff = 16777215 or 16Mb

Allowing a ClientHello as big as this could enable a DoS attack.

If I did my sums right I make the biggest possible valid ClientHello to
be 131396.

But should we allow something as big as this just because its
theoretically possible?

Matt
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT


On 25/09/15 17:05, Alessandro Ghedini via RT wrote:

> On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote:
>> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
>>> 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
>
> Yeah, but OpenSSL first tries to "get" the handshake body and its length before
> parsing it (this is done by ssl3_get_message()). So the "max" argument is
> intended to be used, I imagine, as a sanity check: if the message exceeds that,
> then it's obviously broken and an "illegal parameters" alert is sent. This is
> done regardless of the message type, so the ClientHello parser has to do this
> as well.
>
> This max length check is not exactly smart (e.g. the max size of the SSLv3
> ClientHello is very different from that of TLS) and could probably be removed
> completely, but I don't really know what the consequences of this would be. So
> the best next fix would simply be to provide an approximation of an absolute
> maximum length for the ClientHello (or just use 0xFFFFFF). I opened a pull
> request [0] with just this minimal fix. Anyone is very welcome to propose a
> better fix for this though.

0xffffff = 16777215 or 16Mb

Allowing a ClientHello as big as this could enable a DoS attack.

If I did my sums right I make the biggest possible valid ClientHello to
be 131396.

But should we allow something as big as this just because its
theoretically possible?

Matt


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
On Fri, Sep 25, 2015 at 04:17:33PM +0000, Matt Caswell via RT wrote:

>
>
> On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote:
> >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
> >>> 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
> >
> > Yeah, but OpenSSL first tries to "get" the handshake body and its length before
> > parsing it (this is done by ssl3_get_message()). So the "max" argument is
> > intended to be used, I imagine, as a sanity check: if the message exceeds that,
> > then it's obviously broken and an "illegal parameters" alert is sent. This is
> > done regardless of the message type, so the ClientHello parser has to do this
> > as well.
> >
> > This max length check is not exactly smart (e.g. the max size of the SSLv3
> > ClientHello is very different from that of TLS) and could probably be removed
> > completely, but I don't really know what the consequences of this would be. So
> > the best next fix would simply be to provide an approximation of an absolute
> > maximum length for the ClientHello (or just use 0xFFFFFF). I opened a pull
> > request [0] with just this minimal fix. Anyone is very welcome to propose a
> > better fix for this though.
>
> 0xffffff = 16777215 or 16Mb
>
> Allowing a ClientHello as big as this could enable a DoS attack.
>
> If I did my sums right I make the biggest possible valid ClientHello to
> be 131396.

I updated my patch to use this value now.

> But should we allow something as big as this just because its
> theoretically possible?

As a way of future-proofing OpenSSL (Hubert mentioned a few reasons) or just
to be more standard-compliant I'd say yes, but it's obviously not an urgent
problem.

FWIW I checked a couple of TLS implementations I have around (GnuTLS and s2n),
and AFAICT they don't check for a maximum size at all.

Cheers


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Hubert Kario
(since we're not talking about OpenSSL any more, I'm dropping the RT)

On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> FWIW I checked a couple of TLS implementations I have around (GnuTLS
> and s2n), and AFAICT they don't check for a maximum size at all.

what do you mean by that? As we've said with Matt, you can't create a
valid Client Hello bigger than 131396 bytes...

or do you mean that they accept malformed Client Hello messages?
or that they do accept SSLv3 Client Hellos with arbitrary sized junk at
the end?
--
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
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
In reply to this post by Rich Salz via RT
On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 04:17:33PM +0000, Matt Caswell via RT wrote:
> > On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> > > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT
wrote:
> > >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT
wrote:

> > >>> 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> >
> > > Yeah, but OpenSSL first tries to "get" the handshake body and its
> > > length before parsing it (this is done by ssl3_get_message()). So
> > > the "max" argument is intended to be used, I imagine, as a sanity
> > > check: if the message exceeds that, then it's obviously broken
> > > and an "illegal parameters" alert is sent. This is done
> > > regardless of the message type, so the ClientHello parser has to
> > > do this as well.
> > >
> > > This max length check is not exactly smart (e.g. the max size of
> > > the SSLv3 ClientHello is very different from that of TLS) and
> > > could probably be removed completely, but I don't really know
> > > what the consequences of this would be. So the best next fix
> > > would simply be to provide an approximation of an absolute
> > > maximum length for the ClientHello (or just use 0xFFFFFF). I
> > > opened a pull request [0] with just this minimal fix. Anyone is
> > > very welcome to propose a better fix for this though.
> >
> > 0xffffff = 16777215 or 16Mb
> >
> > Allowing a ClientHello as big as this could enable a DoS attack.
> >
> > If I did my sums right I make the biggest possible valid ClientHello
> > to be 131396.
>
> I updated my patch to use this value now.
embedding magic values is rather bad form.
A define with extended comment describing how we arrived at this value
would be much better

--
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

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alessandro Ghedini
In reply to this post by Hubert Kario
On Fri, Sep 25, 2015 at 07:06:31PM +0200, Hubert Kario wrote:

> (since we're not talking about OpenSSL any more, I'm dropping the RT)
>
> On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> > FWIW I checked a couple of TLS implementations I have around (GnuTLS
> > and s2n), and AFAICT they don't check for a maximum size at all.
>
> what do you mean by that? As we've said with Matt, you can't create a
> valid Client Hello bigger than 131396 bytes...
>
> or do you mean that they accept malformed Client Hello messages?
> or that they do accept SSLv3 Client Hellos with arbitrary sized junk at
> the end?
No and no. I meant that OpenSSL seems to be the only implementation (among the
ones that I checked) to perform maximum length checks on handshake messages.
That is, checking that the message doesn't exceed a pre-defined maximum length
by only looking at the message type and length fields, before even trying to
parse the message body.

The fact that the other libraries don't do this check at all suggests that
increasing the limit in OpenSSL (or even removing the limit completely)
shouldn't affect it negatively.

Cheers

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz via RT
In reply to this post by Rich Salz via RT
On Fri, Sep 25, 2015 at 05:11:39pm +0000, Hubert Kario via RT wrote:

> On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> > On Fri, Sep 25, 2015 at 04:17:33PM +0000, Matt Caswell via RT wrote:
> > > On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> > > > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT
> wrote:
> > > >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT
> wrote:
> > > >>> 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> >
> > > > Yeah, but OpenSSL first tries to "get" the handshake body and its
> > > > length before parsing it (this is done by ssl3_get_message()). So
> > > > the "max" argument is intended to be used, I imagine, as a sanity
> > > > check: if the message exceeds that, then it's obviously broken
> > > > and an "illegal parameters" alert is sent. This is done
> > > > regardless of the message type, so the ClientHello parser has to
> > > > do this as well.
> > > >
> > > > This max length check is not exactly smart (e.g. the max size of
> > > > the SSLv3 ClientHello is very different from that of TLS) and
> > > > could probably be removed completely, but I don't really know
> > > > what the consequences of this would be. So the best next fix
> > > > would simply be to provide an approximation of an absolute
> > > > maximum length for the ClientHello (or just use 0xFFFFFF). I
> > > > opened a pull request [0] with just this minimal fix. Anyone is
> > > > very welcome to propose a better fix for this though.
> > >
> > > 0xffffff = 16777215 or 16Mb
> > >
> > > Allowing a ClientHello as big as this could enable a DoS attack.
> > >
> > > If I did my sums right I make the biggest possible valid ClientHello
> > > to be 131396.
> >
> > I updated my patch to use this value now.
>
> embedding magic values is rather bad form.
> A define with extended comment describing how we arrived at this value
> would be much better

Fair enough. Updated the patch again to do this.

Cheers


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

Sands, Daniel
In reply to this post by Alessandro Ghedini
> > On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> > > FWIW I checked a couple of TLS implementations I have around (GnuTLS
> > > and s2n), and AFAICT they don't check for a maximum size at all.
> >
> > what do you mean by that? As we've said with Matt, you can't create a
> > valid Client Hello bigger than 131396 bytes...
>
> The fact that the other libraries don't do this check at all suggests that
> increasing the limit in OpenSSL (or even removing the limit completely)
> shouldn't affect it negatively.

Actually it suggests that they don't do their due diligence.  If there is not a valid Hello message that is greater than 131396 bytes, then there is no reason to allow for one either.  On the contrary, there is every reason to protect oneself from Godzillagrams.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev