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

[Alessandro Ghedini via RT]

On Fri, Sep 25, 2015 at 02:02:36pm +, 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 +, 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 0xFF (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

Re: [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 +, 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 +, 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 0xFF (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

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

[Alessandro Ghedini via RT]

On Fri, Sep 25, 2015 at 03:02:27pm +, 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 0xFF (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 0xFF). 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

Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3

[Andy Polyakov]

>> > and recognize two new settings,
>> > OPENSSL_NO_ARM_NEON and OPENSSL_ARM_THUMB_ONLY, to accommodate this.
>>
>> While NO_NEON might make sense, I really see no reason to introduce
>> THUMB_ONLY. Because pre-defines set by the compiler driver are
>> sufficient. 
>>
>>
>> You mean, using __thumb__ (predefined for both thumb1 and thumb2)
>> and __thumb2__ (predefined for thumb2 only)?
> 
> Yes.

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=11208dcfb9105e8afa37233185decefd45e89e17
made whole assembly pack Thumb2-friendly, so that now you should be able
to compile all modules. Please, double-check. There is no option to
disable NEON (yet?), because a) I want to expose it to more build cases
to catch eventual bugs; b) would like to suggest idea of supporting
Cortex-M with -march=armv6t2 -mthumb. Latter means that you'll loose
some performance, because it won't utilize word load instruction's
capability to handle misaligned access in ARMv7. But on the other hand
it won't have ideas about compiling NEON, and you'll be excused to think
about which particular Cortex-M is targeted, one will be able to cover
all with single config/buid. Can it be viable compromise? One would
still be able to tune for favorite Mx...

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

[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, );
> 
> 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, 2,
> );
> 
> Why 2? 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


signature.asc
Description: PGP signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



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, );

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).
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, 2,
);

Why 2? No idea.

The same restriction exists in the state-machine-rewrite branches
because I'm ultra-cautious. 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?

Matt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWBWlUAAoJENnE0m0OYESR0GUIAKPpYctFSqG7RVtPI8mKdw75
Ml+18+fOh4QE6RoKVLoBB3FglAZujZ8RMXlOZ6bivF8KrLygoAT6ECF/a0ee3kpk
UAlYOY9HEHistlY+BeAs0jx2VsAKb10mO+Z+C6jV+Uql2GSTFqzrdGSdS6pxOuL1
EJr4WFh32sj+ApvTpDw6XVuvNypVpoEY5KeDj+4ZPKnQdp/TcoErLEzIgzIsGm7b
FNXkpgTy8Xamr+S6afQYgNi6MOlHIIRlOXkDqkOyRpjHfqLU748EympIUkWNq8EZ
dw8Sxk6PRTe9BqgtjX10benF3K7N9yuli2sLHoHFZvwTVqWvNqMgA2jyJIoCgM8=
=bEaO
-END PGP SIGNATURE-

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

[openssl-dev] [openssl.org #4063] 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, );
> 
> 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, 2,
> );
> 
> Why 2? 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


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell via RT]

Gahhhdidn't mean to open this as a new ticket.

Closing.

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

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

[Matt Caswell]

On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 03:02:27pm +, 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 0xFF (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 0xFF). I opened a pull
> request [0] with just this minimal fix. Anyone is very welcome to propose a
> better fix for this though.

0xff = 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

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

[Matt Caswell via RT]

On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 03:02:27pm +, 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 0xFF (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 0xFF). I opened a pull
> request [0] with just this minimal fix. Anyone is very welcome to propose a
> better fix for this though.

0xff = 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

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

[Hubert Kario via RT]

sorry, duplicate of #4063, please close

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

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

[Viktor Dukhovni]

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

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

[Sands, Daniel]

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

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

[Kurt Roeckx]

On Fri, Sep 25, 2015 at 04:23:27PM +, 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

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

[Kurt Roeckx via RT]

On Fri, Sep 25, 2015 at 04:23:27PM +, 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

[openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink

[Stephen Henson via RT]

On Thu Sep 24 11:52:05 2015, steve wrote:
>
> I've tried a newer version of VC++ and I also get the "No Applink"
> error when
> it is trying to embed the fingerprint in libeay32.dll. I'll see if
> this can be
> fixed.

Please try the attached patch.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org



diffs.applink
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Alessandro Ghedini via RT]

On Fri, Sep 25, 2015 at 04:17:33PM +, 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 +, 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 0xFF (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 0xFF). I opened a pull
> > request [0] with just this minimal fix. Anyone is very welcome to propose a
> > better fix for this though.
> 
> 0xff = 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

Re: [openssl-dev] [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

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario via RT]

On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 04:17:33PM +, 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 +, 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 0xFF (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 0xFF). I
> > > opened a pull request [0] with just this minimal fix. Anyone is
> > > very welcome to propose a better fix for this though.
> > 
> > 0xff = 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


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Alessandro Ghedini via RT]

On Fri, Sep 25, 2015 at 05:11:39pm +, 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 +, 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 +, 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 0xFF (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 0xFF). I
> > > > opened a pull request [0] with just this minimal fix. Anyone is
> > > > very welcome to propose a better fix for this though.
> > > 
> > > 0xff = 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

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

[Alessandro Ghedini]

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


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell]

On 25/09/15 20:19, Kurt Roeckx wrote:
> On Fri, Sep 25, 2015 at 04:23:27PM +, 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

Re: [openssl-dev] [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

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

[Viktor Dukhovni]

On Sat, Sep 26, 2015 at 12:17:20AM +, 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

Re: [openssl-dev] Support for TLS SHA2-512?

[Erwann Abalea]

Bonjour,

> Le 24 sept. 2015 à 21:59, Justin Burke  a écrit 
> :
> 
> Hello,
> 
> Does OpenSSL support TLS with SHA2-512? I'm able to compile 1.0.1p with
> SHA2-256 and SHA2-384 support, but not with SHA2-512. `openssl ciphers`
> does not list any SHA512 cipher, while `openssl dgst` does support
> SHA512.

The list of registered cipher suites can be found at
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
 

and there’s no standardized *SHA512 cipher suite, as you can see.

Cordialement,
Erwann Abalea

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

Re: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module

[Dr. Matthias St. Pierre]

On 09/21/2015 12:01 AM, Jan Ehrhardt wrote:
> Dr. Matthias St. Pierre in gmane.comp.encryption.openssl.devel (Sun, 16
> Aug 2015 23:52:21 +0200):
>>
>> Thank you once more for the detailed reply. I applied your patches 
>> provisorily before going on vacation last friday to keep the builds 
>> going. After my vacation we will have to decide what to do about the 
>> FIPS problem.
> 
> Surely, your holiday must be over by now ;-)
> 
> Jan
> 
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 


Sorry for not answering earlier, I overlooked your post. Not because of 
holidays,
but because I was busy with other problems.

As you might have guessed, my provisional arrangement is still in place ;-)
I noticed there has been some movement on issue #4042 recently and hope there
will be an official solution to the problem soon.

Thanks for persisting on the subject, anyway.

Regards,
Matthias
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Support for TLS SHA2-512?

[stefan.n...@t-online.de]

   Hi,

> Does OpenSSL support TLS with SHA2-512?

No, since there is no such thing as a TLS cipher suite with SHA512.
Cipher suites need to be registered and assigned IDs, so servers/clients
can exchange those IDs to announce what cipher suites they support.
And if you look at the probably most up-to-date list of currently registered
cipher suites at 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
you'll see that there simply is no cipher suite using SHA512.
The rational for this is that SHA-384 already offers the same level
of security as the 256 bit block ciphers do, so there's no point in using
longer hashes.

   Regards,
   Stefan


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

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Hubert Kario]

On Friday 25 September 2015 11:40:27 Matt Caswell wrote:
> On 25/09/15 11:25, Hubert Kario via RT wrote:
> > On Friday 25 September 2015 10:47:42 Matt Caswell wrote:
> >> However, I have some concerns with the wording of the RFC. It seems
> >> to place no limits whatsoever on when it is valid to receive app
> >> data in the handshake. By the wording in the RFC it would be valid
> >> for app data to be received *after* the ChangeCipherSpec has been
> >> received but *before* the Finished has been processed. This seems
> >> dangerous to me because it is not until the Finished is processed
> >> that we verify the handshake data MAC - and yet we could already
> >> have acted upon app data received. I assume the intent was to
> >> allow the interleaved app data only up until the point that the
> >> CCS is received. I have attached a patch for 1.0.2 that implements
> >> that logic.
> > 
> > yes, I think the only place in which the handshake protocol and
> > application data _can't_ be interleaved is between the CCS and
> > Finished.
> It would be nice to have a test for that wouldn't it ;-)

yeah, but it will be hard to do, you know, with it requiring an TLS 
implementation to misbehave ;)

I'll make one as soon as I'll finish the test cases for record layer 
fragmentation of initial Client Hello (there are few bugs there too)

-- 
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: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Hubert Kario]

On Friday 25 September 2015 12:42:14 Karthikeyan Bhargavan wrote:
> During renegotiation, app data should not appear between CCS and
> finished, but some implementations (e.g. NSS) do allow this. I would
> consider it a state machine bug, although finding a serious exploit
> is not so easy.

while it is not easy, patching it up before it is exploitable is a good 
idea.

And besides, we already had enough issues with clients and servers 
incorrectly attaching data to wrong authentication info.
Some implementations may think that stuff before Finished is from new 
connection while others that it is from old connection.

I'll file that bug as soon as I have a reproducer for it (most likely 
today)
-- 
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: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell]

On 25/09/15 11:25, Hubert Kario via RT wrote:
> 
>   A Finished message is always sent immediately after a change
>   cipher spec message to verify that the key exchange and
>   authentication processes were successful.

This is perhaps the key statement. It could do with being more explicit
if the intent here is to disallow interleaved app data.

Matt

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

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell]

On 25/09/15 11:25, Hubert Kario via RT wrote:
> On Friday 25 September 2015 10:47:42 Matt Caswell wrote:
>> However, I have some concerns with the wording of the RFC. It seems to
>> place no limits whatsoever on when it is valid to receive app data in
>> the handshake. By the wording in the RFC it would be valid for app
>> data to be received *after* the ChangeCipherSpec has been received
>> but *before* the Finished has been processed. This seems dangerous to
>> me because it is not until the Finished is processed that we verify
>> the handshake data MAC - and yet we could already have acted upon app
>> data received. I assume the intent was to allow the interleaved app
>> data only up until the point that the CCS is received. I have
>> attached a patch for 1.0.2 that implements that logic.
> 
> yes, I think the only place in which the handshake protocol and 
> application data _can't_ be interleaved is between the CCS and Finished.

It would be nice to have a test for that wouldn't it ;-)

Matt

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

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Karthikeyan Bhargavan]

During renegotiation, app data should not appear between CCS and finished, but 
some implementations (e.g. NSS) do allow this.
I would consider it a state machine bug, although finding a serious exploit is 
not so easy.

> On 25 Sep 2015, at 12:40, Matt Caswell  wrote:
> 
> 
> 
> On 25/09/15 11:25, Hubert Kario via RT wrote:
>> On Friday 25 September 2015 10:47:42 Matt Caswell wrote:
>>> However, I have some concerns with the wording of the RFC. It seems to
>>> place no limits whatsoever on when it is valid to receive app data in
>>> the handshake. By the wording in the RFC it would be valid for app
>>> data to be received *after* the ChangeCipherSpec has been received
>>> but *before* the Finished has been processed. This seems dangerous to
>>> me because it is not until the Finished is processed that we verify
>>> the handshake data MAC - and yet we could already have acted upon app
>>> data received. I assume the intent was to allow the interleaved app
>>> data only up until the point that the CCS is received. I have
>>> attached a patch for 1.0.2 that implements that logic.
>> 
>> yes, I think the only place in which the handshake protocol and 
>> application data _can't_ be interleaved is between the CCS and Finished.
> 
> It would be nice to have a test for that wouldn't it ;-)
> 
> Matt
> 
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[openssl-dev] [openssl.org #4062] [PATCH] Fix build failure

[Alessandro Ghedini via RT]

Hello,

due to commit a93d3e0 the ./config script currently fails with the error:

> Operating system: x86_64-whatever-linux2
> This system (linux-x86_64) is not supported. See file INSTALL for details.

see the following GitHub pull request for a fix:
https://github.com/openssl/openssl/pull/412

Cheers

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

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

[Hubert Kario 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


signature.asc
Description: PGP signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Alessandro Ghedini via RT]

On Fri, Sep 25, 2015 at 01:20:12pm +, 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

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell]

On 24/09/15 21:40, Hubert Kario via RT wrote:
> I have made the reproducer cleaner and it should use relatively stable 
> API's of tlsfuzzer now.
> 
> 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
> 
> pip install --pre tlslite-ng
> git clone https://github.com/tomato42/tlsfuzzer.git
> 
> cd tlsfuzzer
> PYTHONPATH=. python scripts/test-openssl-3712.py

This is really nice! Thanks Hubert.

I've been looking into this issue. The reason this fails is because at
some point in the past there has been an explicit design decision to
disallow it. The relevant code is here:

/*
 * At this point, we were expecting handshake data, but have
 * application data.  If the library was running inside ssl3_read()
 * (i.e. in_read_app_data is set) and it makes sense to read
 * application data at this point (session renegotiation not yet
 * started), we will indulge it.
 */
if (s->s3->in_read_app_data &&
(s->s3->total_renegotiations != 0) &&
(((s->state & SSL_ST_CONNECT) &&
  (s->state >= SSL3_ST_CW_CLNT_HELLO_A) &&
  (s->state <= SSL3_ST_CR_SRVR_HELLO_A)
 ) || ((s->state & SSL_ST_ACCEPT) &&
   (s->state <= SSL3_ST_SW_HELLO_REQ_A) &&
   (s->state >= SSL3_ST_SR_CLNT_HELLO_A)
 )
)) {
s->s3->in_read_app_data = 2;
return (-1);
} else {
al = SSL_AD_UNEXPECTED_MESSAGE;
SSLerr(SSL_F_SSL3_READ_BYTES, SSL_R_UNEXPECTED_RECORD);
goto f_err;
}

So to pull this conditional apart a bit:

s->s3->in_read_app_data : we were originally called by SSL_read

AND

s->s3->total_renegotiations != 0 : we have started at least one
renegotiation at some point (*see below)

AND

(
  ((s->state & SSL_ST_CONNECT) &&
  (s->state >= SSL3_ST_CW_CLNT_HELLO_A) &&
  (s->state <= SSL3_ST_CR_SRVR_HELLO_A) : we are a client and are in a
  state where we have started to write/have finished writing a
  ClientHello out but have not yet received a ServerHello.

  OR

  (s->state & SSL_ST_ACCEPT) &&
  (s->state <= SSL3_ST_SW_HELLO_REQ_A) &&
  (s->state >= SSL3_ST_SR_CLNT_HELLO_A) : we are a server and are about
to write a HelloVerifyRequest, or we are in the process of reading a
ClientHello

)


Aside from whether this is the correct logic or not I think there is a
related bug here in the total_renegotiations value. I believe this is
intended to count up the number of renegotiations that have occurred. As
far as I can determine this is incremented when:
- There is an explicit call to SSL_renegotiate() or
SSL_renegotiate_abbreviated()
OR
- As a client we initiate a renegotiation following receipt of a
HelloRequest

So it does not seem to get incremented when, as a server and after the
initial handshake has completed, we receive an unsolicited ClientHello,
i.e. client initiated renegotiation as in your reproducer code. This
alone is sufficient for your test case to fail, but even fixing it won't
solve the problem due to the intent of the logic above.

The above logic can be traced back to this commit:

commit b35e9050f282c5ea2164bd5b08ed34d03accf45f
Author: Bodo Möller 
AuthorDate: Sun Feb 20 23:04:06 2000 +
Commit: Bodo Möller 
CommitDate: Sun Feb 20 23:04:06 2000 +

Tolerate fragmentation and interleaving in the SSL 3/TLS record layer.


Note the date of February 2000! The OP correctly cites RFC 5246 (TLS1.2)
and RFC 4346 (TLS1.1) as follows:

   Note: Data of different TLS Record layer content types MAY be
   interleaved.  Application data is generally of lower precedence for
   transmission than other content types.  However, records MUST be
   delivered to the network in the same order as they are protected by
   the record layer.  Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.

As the OP also observes:
"The last sentence clearly puts the blame on OpenSSL.
This seems to be an addition in TLS 1.1 since it cannot be found in RFC
2246."

Clearly the code commit pre-dates the publication of TLS1.1 (April 2006)
and is a carry over from the ambiguous situation as it is in TLS1.0.
Therefore this does seem to be an OpenSSL bug.

However, I have some concerns with the wording of the RFC. It seems to
place no limits whatsoever on when it is valid to receive app data in
the handshake. By the wording in the RFC it would be valid for app data
to be received *after* the ChangeCipherSpec has been received but
*before* the Finished has been processed. This seems dangerous to me
because it is not until the Finished is processed that we verify the
handshake data MAC - and yet we could already have acted upon app data
received. I assume the intent was to allow 

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 24/09/15 21:40, Hubert Kario via RT wrote:
> I have made the reproducer cleaner and it should use relatively stable 
> API's of tlsfuzzer now.
> 
> 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
> 
> pip install --pre tlslite-ng
> git clone https://github.com/tomato42/tlsfuzzer.git
> 
> cd tlsfuzzer
> PYTHONPATH=. python scripts/test-openssl-3712.py

This is really nice! Thanks Hubert.

I've been looking into this issue. The reason this fails is because at
some point in the past there has been an explicit design decision to
disallow it. The relevant code is here:

/*
 * At this point, we were expecting handshake data, but have
 * application data.  If the library was running inside ssl3_read()
 * (i.e. in_read_app_data is set) and it makes sense to read
 * application data at this point (session renegotiation not yet
 * started), we will indulge it.
 */
if (s->s3->in_read_app_data &&
(s->s3->total_renegotiations != 0) &&
(((s->state & SSL_ST_CONNECT) &&
  (s->state >= SSL3_ST_CW_CLNT_HELLO_A) &&
  (s->state <= SSL3_ST_CR_SRVR_HELLO_A)
 ) || ((s->state & SSL_ST_ACCEPT) &&
   (s->state <= SSL3_ST_SW_HELLO_REQ_A) &&
   (s->state >= SSL3_ST_SR_CLNT_HELLO_A)
 )
)) {
s->s3->in_read_app_data = 2;
return (-1);
} else {
al = SSL_AD_UNEXPECTED_MESSAGE;
SSLerr(SSL_F_SSL3_READ_BYTES, SSL_R_UNEXPECTED_RECORD);
goto f_err;
}

So to pull this conditional apart a bit:

s->s3->in_read_app_data : we were originally called by SSL_read

AND

s->s3->total_renegotiations != 0 : we have started at least one
renegotiation at some point (*see below)

AND

(
  ((s->state & SSL_ST_CONNECT) &&
  (s->state >= SSL3_ST_CW_CLNT_HELLO_A) &&
  (s->state <= SSL3_ST_CR_SRVR_HELLO_A) : we are a client and are in a
  state where we have started to write/have finished writing a
  ClientHello out but have not yet received a ServerHello.

  OR

  (s->state & SSL_ST_ACCEPT) &&
  (s->state <= SSL3_ST_SW_HELLO_REQ_A) &&
  (s->state >= SSL3_ST_SR_CLNT_HELLO_A) : we are a server and are about
to write a HelloVerifyRequest, or we are in the process of reading a
ClientHello

)


Aside from whether this is the correct logic or not I think there is a
related bug here in the total_renegotiations value. I believe this is
intended to count up the number of renegotiations that have occurred. As
far as I can determine this is incremented when:
- There is an explicit call to SSL_renegotiate() or
SSL_renegotiate_abbreviated()
OR
- As a client we initiate a renegotiation following receipt of a
HelloRequest

So it does not seem to get incremented when, as a server and after the
initial handshake has completed, we receive an unsolicited ClientHello,
i.e. client initiated renegotiation as in your reproducer code. This
alone is sufficient for your test case to fail, but even fixing it won't
solve the problem due to the intent of the logic above.

The above logic can be traced back to this commit:

commit b35e9050f282c5ea2164bd5b08ed34d03accf45f
Author: Bodo Möller 
AuthorDate: Sun Feb 20 23:04:06 2000 +
Commit: Bodo Möller 
CommitDate: Sun Feb 20 23:04:06 2000 +

Tolerate fragmentation and interleaving in the SSL 3/TLS record layer.


Note the date of February 2000! The OP correctly cites RFC 5246 (TLS1.2)
and RFC 4346 (TLS1.1) as follows:

   Note: Data of different TLS Record layer content types MAY be
   interleaved.  Application data is generally of lower precedence for
   transmission than other content types.  However, records MUST be
   delivered to the network in the same order as they are protected by
   the record layer.  Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.

As the OP also observes:
"The last sentence clearly puts the blame on OpenSSL.
This seems to be an addition in TLS 1.1 since it cannot be found in RFC
2246."

Clearly the code commit pre-dates the publication of TLS1.1 (April 2006)
and is a carry over from the ambiguous situation as it is in TLS1.0.
Therefore this does seem to be an OpenSSL bug.

However, I have some concerns with the wording of the RFC. It seems to
place no limits whatsoever on when it is valid to receive app data in
the handshake. By the wording in the RFC it would be valid for app data
to be received *after* the ChangeCipherSpec has been received but
*before* the Finished has been processed. This seems dangerous to me
because it is not until the Finished is processed that we verify the
handshake data MAC - and yet we could already have acted upon app data
received. I assume the intent was to allow 

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Hubert Kario via RT]

On Friday 25 September 2015 10:47:42 Matt Caswell wrote:
> However, I have some concerns with the wording of the RFC. It seems to
> place no limits whatsoever on when it is valid to receive app data in
> the handshake. By the wording in the RFC it would be valid for app
> data to be received *after* the ChangeCipherSpec has been received
> but *before* the Finished has been processed. This seems dangerous to
> me because it is not until the Finished is processed that we verify
> the handshake data MAC - and yet we could already have acted upon app
> data received. I assume the intent was to allow the interleaved app
> data only up until the point that the CCS is received. I have
> attached a patch for 1.0.2 that implements that logic.

yes, I think the only place in which the handshake protocol and 
application data _can't_ be interleaved is between the CCS and Finished.

Or in other words, the following sections from RFC 5246 apply:

   Application data MUST NOT be sent prior to the
   completion of the first handshake (before a cipher suite other than
   TLS_NULL_WITH_NULL_NULL is established).

and:

  A Finished message is always sent immediately after a change
  cipher spec message to verify that the key exchange and
  authentication processes were successful. 

and:

   It is a fatal error if a Finished message is not preceded by a
   ChangeCipherSpec message at the appropriate point in the handshake.

isn't overruled by:

   Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.
-- 
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

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

[Hubert Kario via RT]

On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 01:20:12pm +, 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


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4062] [PATCH] Fix build failure

[Matt Caswell via RT]

Patch applied. Thanks.

Matt

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

[openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL

[Matt Caswell via RT]

Closing this ticket. Please use the API suggested by Steve.

Matt

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

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Hubert Kario]

On Friday 25 September 2015 14:20:40 Hubert Kario wrote:
> On Friday 25 September 2015 11:40:27 Matt Caswell wrote:
> > On 25/09/15 11:25, Hubert Kario via RT wrote:
> > > On Friday 25 September 2015 10:47:42 Matt Caswell wrote:
> > >> However, I have some concerns with the wording of the RFC. It
> > >> seems
> > >> to place no limits whatsoever on when it is valid to receive app
> > >> data in the handshake. By the wording in the RFC it would be
> > >> valid
> > >> for app data to be received *after* the ChangeCipherSpec has been
> > >> received but *before* the Finished has been processed. This seems
> > >> dangerous to me because it is not until the Finished is processed
> > >> that we verify the handshake data MAC - and yet we could already
> > >> have acted upon app data received. I assume the intent was to
> > >> allow the interleaved app data only up until the point that the
> > >> CCS is received. I have attached a patch for 1.0.2 that
> > >> implements
> > >> that logic.
> > > 
> > > yes, I think the only place in which the handshake protocol and
> > > application data _can't_ be interleaved is between the CCS and
> > > Finished.
> > 
> > It would be nice to have a test for that wouldn't it ;-)
> 
> yeah, but it will be hard to do, you know, with it requiring an TLS
> implementation to misbehave ;)
> 
> I'll make one as soon as I'll finish the test cases for record layer
> fragmentation of initial Client Hello (there are few bugs there too)

and done, in the same repo just run
scripts/test-interleaved-application-data-in-renegotiation.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

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev