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

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

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

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

_______________________________________________
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 #4065] Re: Client Hello longer than 2^14 bytes are rejected

Kurt Roeckx
On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote:
>
> 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.

Since we don't actually know how things are going to change in the
future and that they can change the maximum size of a Client
Hello, it makes sense to me to not enforce a limit for the Client
Hello message just because that's what the current version only
supports.  For all other messages we should be able to tell what
the maximum size is.


Kurt

_______________________________________________
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 #4065] Re: Client Hello longer than 2^14 bytes are rejected

Rich Salz via RT
On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote:
>
> 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.

Since we don't actually know how things are going to change in the
future and that they can change the maximum size of a Client
Hello, it makes sense to me to not enforce a limit for the Client
Hello message just because that's what the current version only
supports.  For all other messages we should be able to tell what
the maximum size is.


Kurt


_______________________________________________
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 #4065] Re: Client Hello longer than 2^14 bytes are rejected

Viktor Dukhovni
In reply to this post by Kurt Roeckx
On Fri, Sep 25, 2015 at 09:19:02PM +0200, Kurt Roeckx wrote:

> Since we don't actually know how things are going to change in the
> future and that they can change the maximum size of a Client
> Hello, it makes sense to me to not enforce a limit for the Client
> Hello message just because that's what the current version only
> supports.  For all other messages we should be able to tell what
> the maximum size is.

There's no such thing as "no limit".  If the client HELLO retains
its basic structure, it needs to retain the same limits.

If the limits change, that's a new protocol message that is no
longer an SSLv3/TLSv1.0 compatible client HELLO.

The published limits from TLS 1.2 cannot change in TLS 1.3, if TLS
1.3 HELLO messages are to be understood by TLS 1.2 servers.

--
        Viktor.
_______________________________________________
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 #4065] Re: Client Hello longer than 2^14 bytes are rejected

Matt Caswell-2
In reply to this post by Kurt Roeckx


On 25/09/15 20:19, Kurt Roeckx wrote:

> On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote:
>>
>> 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.
>
> Since we don't actually know how things are going to change in the
> future and that they can change the maximum size of a Client
> Hello, it makes sense to me to not enforce a limit for the Client
> Hello message just because that's what the current version only
> supports.  For all other messages we should be able to tell what
> the maximum size is.

If the ClientHello message is longer than 131396 bytes then either we
are under some kind attack, or it is in some future format that we do
not understand and is not backwards compatible (a requirement of
backwards compatibility would be that it is under or equal to that
limit). Either way we should drop the message.

My concern is whether we should have a limit that is less than that. A
default s_client ClientHello on master at the moment is 364 bytes. A
default ClientHello with a ticket is 556 bytes. The biggest ClientHello
I can induce from s_client is one including a ticket and a cipher string
of "ALL:@SECLEVEL=0" which leads to 618 bytes. I recognise that we are
talking about future proofing; but the current limit of 16384 already
gives us the ability to accept ClientHello's 26 times bigger than the
biggest s_client can create today. That is significant room for future
growth.

On the other side of the coin handling very large ClientHello's is not
without cost and risk. There is bandwidth consumption, memory
consumption, CPU consumption handling any operations required from the
ClientHello (e.g. decrypting an enormous SessionTicket) etc. We also
have to bear in mind the OpenSSL doesn't necessarily just run on big
powerful servers in datacentres. It can also runs in very resource
constrained environments. We potentially open up our users to DoS
attacks by attempting to accept these "godzillagram" (as someone called
them) ClientHellos. Right now, today, if a server starts receiving
ClientHello's that big then it is almost certainly an attack. Increasing
the maximum size over what we have today increases the risk of attacks
right now.

Of course we don't know what the future will bring. I'm struggling to
foresee a scenario where we have a vast explosion in the ciphersuites
available (which is where a significant proportion of the "allowed"
ClientHello size is allocated) - but I guess it could happen. Possibly
more likely is some new extension(s) requiring very large extension data
blocks. Still, whatever that extension is, it would have to be
*massively* bigger than any extension we have today to blow the existing
limit - and absolutely HUGE to go anywhere near 131396. The latency
costs of managing such large ClientHello's would be significant so I am
really finding it hard to see a future where ClientHello's get even
close to approaching the kind of sizes we're talking about. So why would
we open up our users today to increased risks for a future that seems
quite unlikely?

So, what I'm trying to say is it's a balancing act. We shouldn't just
accept the biggest possible messages that we can just because that gives
us the best interoperability for the future. There are other
considerations.

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 #4065] Re: Client Hello longer than 2^14 bytes are rejected

Salz, Rich

> On the other side of the coin handling very large ClientHello's is not without
> cost and risk.

As long as it's a #define that can be changed in ssl.h (or a runtime global? Ick) we should be okay.

_______________________________________________
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 #4065] Re: Client Hello longer than 2^14 bytes are rejected

Viktor Dukhovni
On Sat, Sep 26, 2015 at 12:17:20AM +0000, Salz, Rich wrote:

> > On the other side of the coin handling very large ClientHello's is not without
> > cost and risk.
>
> As long as it's a #define that can be changed in ssl.h (or a runtime global? Ick) we should be okay.

It would have to more configurable than that to be worth the bother.
All sorts of "appliance" products with OpenSSL inside would
potentially some day pose a barrier to interoperability with clients
that send large HELLO messages.

I should note that server side session state can also contain a
client certificate, which is then embedded in the session ticket.
So the outer limits of current practice are somewhat bigger.

We could perhaps increase the limit from 16K to 32K bytes, just in
case that helps, and hope that the result does not expose servers
to significantly higher risk of DoS.

Or raise the issue on the TLS WG.  Are servers really expected
to support up to 128K or so of client HELLO?

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

[openssl.org #4063] Re: [openssl.org #4065] Re: 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 19:19:12 Kurt Roeckx via RT wrote:

> On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote:
> > 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.
>
> Since we don't actually know how things are going to change in the
> future and that they can change the maximum size of a Client
> Hello, it makes sense to me to not enforce a limit for the Client
> Hello message just because that's what the current version only
> supports.  For all other messages we should be able to tell what
> the maximum size is.
It was already raised on the IETF mailing list and nobody disagreed that
any future Client Hello messages need to be compatible for previous
protocol versions.

And that was in context of TLS 1.3 and quantum resistant crypto.

Finally, there are implementations that do follow the specification to
the letter - e.g. Mozilla NSS.
--
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 #4065] Re: Client Hello longer than 2^14 bytes are rejected

Hubert Kario
In reply to this post by Viktor Dukhovni
On Saturday 26 September 2015 01:02:15 Viktor Dukhovni wrote:

> On Sat, Sep 26, 2015 at 12:17:20AM +0000, Salz, Rich wrote:
> > > On the other side of the coin handling very large ClientHello's is
> > > not without cost and risk.
> >
> > As long as it's a #define that can be changed in ssl.h (or a runtime
> > global? Ick) we should be okay.
> It would have to more configurable than that to be worth the bother.
> All sorts of "appliance" products with OpenSSL inside would
> potentially some day pose a barrier to interoperability with clients
> that send large HELLO messages.
>
> I should note that server side session state can also contain a
> client certificate, which is then embedded in the session ticket.
> So the outer limits of current practice are somewhat bigger.
>
> We could perhaps increase the limit from 16K to 32K bytes, just in
> case that helps, and hope that the result does not expose servers
> to significantly higher risk of DoS.
>
> Or raise the issue on the TLS WG.  Are servers really expected
> to support up to 128K or so of client HELLO?
TLS 1.3 Client Hello will contain client key shares for _multiple_ key
exchange methods (sending both DH 2048 and ECDH 256 is rather likely).

Then we have session tickets, which for case with client certificates
can easily be few kilobytes in size (there are "godzillacerts" that are
bigger than 16KiB already out there).

So I have to retract my initial "unlikely" and "never" and say that even
for standard TLSv1.2 with commonly used extensions a Client Hello bigger
than 16KiB is not out of the question.

Client Hello messages of at least 2^16+σ MUST be accepted. Question is,
how big the σ needs to be, likely 1KiB at the very least.

I'd still say that it's just kicking the can down the road.

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