[openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Stephen Henson via RT]

On Sun May 01 07:32:17 2016, hen...@newdawn.dk wrote:
> Thank you all for the assistance - trying to convince Qt/C++ SSL
> sockets to do as you've described by cutting down on ciphers. I did
> check std Google Chrome ClientHello which does only contain about 10
> cipher suites - where Qt seems to include a lot more (all supported) -
> so what i'm trying to determine now is which can I safely skip - based
> on name , bit, protocol - this is for a web browser so if anyone have
> any insight into which ciphers makes sense here that'd be greatly
> appreciated - for now i'm trying to just use the same as other
> browsers.

Ah I should've been a bit clearer. The -bugs option does *not* cut down the
number of ciphersuites it adds a bug workaround. If you set the flag
SSL_OP_TLSEXT_PADDING it should work with that server.

In a bit more detail. The original problem was triggered by a ClientHello 256
or more bytes in size and is the load balancer bug. After some consultation
with the vendor it turns out that the bug is triggered by a ClientHello between
256 and 511 bytes in size.So a workaround was developed that pads the
ClientHello so it exceeds 511 bytes in size if it would otherwise be between
256 and 511 bytes.

That's what that flag does if you set it.

So why isn't this the default behaviour of OpenSSL? Well it was at one point
but it turned out a separate implementation (which was OK otherwise) couldn't
handle the larger ClientHello with padding. So some buggy servers choke without
the flag and some with it.

The proper fix of course is for the affected server to update its load
balancing software: the bug is actually several years old now.

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

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Henrik Hofmeister via RT]

Thank you all for the assistance - trying to convince Qt/C++ SSL sockets to do 
as you've described by cutting down on ciphers. I did check std Google Chrome 
ClientHello which does only contain about 10 cipher suites - where Qt seems to 
include a lot more (all supported) - so what i'm trying to determine now is 
which can I safely skip - based on name , bit, protocol - this is for a web 
browser so if anyone have any insight into which ciphers makes sense here 
that'd be greatly appreciated - for now i'm trying to just use the same as 
other browsers.
Thank you again!





On Sat, Apr 30, 2016 at 5:44 PM -0700, "Stephen Henson via RT" 
 wrote:










On Sat Apr 30 21:23:30 2016, hen...@newdawn.dk wrote:
> Since this is a MS IIS 7.0 server I would argue that it'd be in the
> interest of openssl to handle the situation rather than accept this
> scenario - since IIS is likely powering more than a few hosts? It is
> possible to have the host correctly list its supported protocols using
> nmap - i'd assume the TLS1.2 attempt can be avoided altogether (
> without knowing any implementation details or if tht adds overhead
> though ) ?
>

As others have indicated this is a known bug with a load balancer and not IIS.

As well as the solutions suggested you can try the -bugs option to s_client
which pads client hellos to workaround this issue.

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

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted







-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Stephen Henson via RT]

On Sat Apr 30 21:23:30 2016, hen...@newdawn.dk wrote:
> Since this is a MS IIS 7.0 server I would argue that it'd be in the
> interest of openssl to handle the situation rather than accept this
> scenario - since IIS is likely powering more than a few hosts? It is
> possible to have the host correctly list its supported protocols using
> nmap - i'd assume the TLS1.2 attempt can be avoided altogether (
> without knowing any implementation details or if tht adds overhead
> though ) ?
>

As others have indicated this is a known bug with a load balancer and not IIS.

As well as the solutions suggested you can try the -bugs option to s_client
which pads client hellos to workaround this issue.

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

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Viktor Dukhovni]

> On Apr 30, 2016, at 5:26 PM, Salz, Rich  wrote:
> 
>> Since this is a MS IIS 7.0 server I would argue that it'd be in the interest 
>> of
>> openssl to handle the situation rather than accept this scenario - since IIS 
>> is
>> likely powering more than a few hosts?
> 
> It's a known bug, and openssl can work-around the bug by configuring as 
> described.

To be clear, it is a known issue in some F5 load-balancers that has been 
addressed
since, and a few other rather unusual systems.  All systems that have trouble 
with
the larger TLS client HELLO should have been patched by now, and the problem is
entirely on their end.

I should also add that in OpenSSL 1.1.0 a lot of TLS ciphers that are obsolete
or unnecessary baggage have been phased out.  So the 1.1.0 release may well
be more interoperable with such servers.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Salz, Rich]

> Since this is a MS IIS 7.0 server I would argue that it'd be in the interest 
> of
> openssl to handle the situation rather than accept this scenario - since IIS 
> is
> likely powering more than a few hosts?

It's a known bug, and openssl can work-around the bug by configuring as 
described.




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

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Salz, Rich via RT]

> Since this is a MS IIS 7.0 server I would argue that it'd be in the interest 
> of
> openssl to handle the situation rather than accept this scenario - since IIS 
> is
> likely powering more than a few hosts?

It's a known bug, and openssl can work-around the bug by configuring as 
described.





-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Henrik Hofmeister via RT]

Since this is a MS IIS 7.0 server I would argue that it'd be in the interest of 
openssl to handle the situation rather than accept this scenario - since IIS is 
likely powering more than a few hosts? It is possible to have the host 
correctly list its supported protocols using nmap - i'd assume the TLS1.2 
attempt can be avoided altogether ( without knowing any implementation details 
or if tht adds overhead though ) ?





On Sat, Apr 30, 2016 at 1:59 PM -0700, "Matt Caswell via RT"  
wrote:










On Sat Apr 30 19:51:51 2016, hen...@newdawn.dk wrote:
> Hi there
>
> I've recently come across what looks to be an internal bug in openssl:
>
> Original symptoms was that neither "curl" or "wget" could access the
> following site:
>
> https://coverage.tre.se - this site is using TLS 1.0 (only) and does
> have some pretty crazy certificate issues - but does show up "green"
> in most browsers (Unless you're on a system with an openssl which
> supports TLS 1.2 ).
>
> Accessing the site (curl / wget) hangs during SSL handshake.
>
> I then tried:
> openssl s_client -connect coverage.tre.se:443 which hangs as well
>
> By forcing the protocol to TLS1.0 it will correctly parse and see the
> certificate. By forcing protocol to TLS1.1 it'll correctly error out
> saying invalid protocol. Even just telling s_client to not include TLS
> 1.2 will make it work as expected.
>
> So to sum up:
>
> My guess would be that some incompatibility between the 1.0 and 1.2
> protocol causes 1.2 to not determine correctly that the server does
> not support it , and as such is unable to fallback to previous
> versions.
>
> I have verified this on several ubuntu 14.04 machines with the
> following openssl versions:
>
> OpenSSL 1.0.1f 6 Jan 2014
>
>
> OpenSSL 1.0.2g 1 Mar 2016
>
> And I've verified that it does work as expected on OSX which has a
> openssl version that does not support TLS 1.2:
>
> OpenSSL 0.9.8zg 14 July 2015
>
> Hope this helps resolve the issue.

This is not a bug in OpenSSL. The problem here is that the server is behaving
incorrectly when receiving large ClientHello messages. The ClientHello is the
first message that is sent from the client to the server. If a large
ClientHello is received then the server just hangs. The reason that this
impacts TLSv1.2 and not other versions is that there are more ciphersuites
available for that protocol version and therefore the ClientHello is bigger.

You can verify that it all works correctly by restricting the number of
ciphersuites that the client sends in its ClientHello. E.g. just sending one
ciphersuite:

openssl s_client -connect coverage.tre.se:443 cipher AES128-SHA

The above command works fine and successfully connects. If fixing the server is
not an option then a simple workaround is to define a ciphersuite selection
string that restricts the ciphersuites to a smaller set.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted







-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Kurt Roeckx via RT]

On Sat, Apr 30, 2016 at 08:59:46PM +, Matt Caswell via RT wrote:
> 
> This is not a bug in OpenSSL. The problem here is that the server is behaving
> incorrectly when receiving large ClientHello messages. The ClientHello is the
> first message that is sent from the client to the server. If a large
> ClientHello is received then the server just hangs. The reason that this
> impacts TLSv1.2 and not other versions is that there are more ciphersuites
> available for that protocol version and therefore the ClientHello is bigger.

This is a know problem in old versions of F5 BIG-IP product.

See:
https://support.f5.com/kb/en-us/solutions/public/14000/700/sol14758.html


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Matt Caswell via RT]

On Sat Apr 30 19:51:51 2016, hen...@newdawn.dk wrote:
> Hi there
>
> I've recently come across what looks to be an internal bug in openssl:
>
> Original symptoms was that neither "curl" or "wget" could access the
> following site:
>
> https://coverage.tre.se - this site is using TLS 1.0 (only) and does
> have some pretty crazy certificate issues - but does show up "green"
> in most browsers (Unless you're on a system with an openssl which
> supports TLS 1.2 ).
>
> Accessing the site (curl / wget) hangs during SSL handshake.
>
> I then tried:
> openssl s_client -connect coverage.tre.se:443 which hangs as well
>
> By forcing the protocol to TLS1.0 it will correctly parse and see the
> certificate. By forcing protocol to TLS1.1 it'll correctly error out
> saying invalid protocol. Even just telling s_client to not include TLS
> 1.2 will make it work as expected.
>
> So to sum up:
>
> My guess would be that some incompatibility between the 1.0 and 1.2
> protocol causes 1.2 to not determine correctly that the server does
> not support it , and as such is unable to fallback to previous
> versions.
>
> I have verified this on several ubuntu 14.04 machines with the
> following openssl versions:
>
> OpenSSL 1.0.1f 6 Jan 2014
>
>
> OpenSSL 1.0.2g 1 Mar 2016
>
> And I've verified that it does work as expected on OSX which has a
> openssl version that does not support TLS 1.2:
>
> OpenSSL 0.9.8zg 14 July 2015
>
> Hope this helps resolve the issue.

This is not a bug in OpenSSL. The problem here is that the server is behaving
incorrectly when receiving large ClientHello messages. The ClientHello is the
first message that is sent from the client to the server. If a large
ClientHello is received then the server just hangs. The reason that this
impacts TLSv1.2 and not other versions is that there are more ciphersuites
available for that protocol version and therefore the ClientHello is bigger.

You can verify that it all works correctly by restricting the number of
ciphersuites that the client sends in its ClientHello. E.g. just sending one
ciphersuite:

openssl s_client -connect coverage.tre.se:443 cipher AES128-SHA

The above command works fine and successfully connects. If fixing the server is
not an option then a simple workaround is to define a ciphersuite selection
string that restricts the ciphersuites to a smaller set.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Henrik Hofmeister via RT]

Hi there

I've recently come across what looks to be an internal bug in openssl:

Original symptoms was that neither "curl" or "wget" could access the following 
site: 

https://coverage.tre.se - this site is using TLS 1.0 (only) and does have some 
pretty crazy certificate issues - but does show up "green" in most browsers 
(Unless you're on a system with an openssl which supports TLS 1.2 ).

Accessing the site (curl / wget) hangs during SSL handshake.

I then tried: 
openssl s_client -connect coverage.tre.se:443 which hangs as well

By forcing the protocol to TLS1.0 it will correctly parse and see the 
certificate. By forcing protocol to TLS1.1 it'll correctly error out saying 
invalid protocol. Even just telling s_client to not include TLS 1.2 will make 
it work as expected.

So to sum up: 

My guess would be that some incompatibility between the 1.0 and 1.2 protocol 
causes 1.2 to not determine correctly that the server does not support it , and 
as such is unable to fallback to previous versions. 

I have verified this on several ubuntu 14.04 machines with the following 
openssl versions: 

OpenSSL 1.0.1f 6 Jan 2014


OpenSSL 1.0.2g 1 Mar 2016

And I've verified that it does work as expected on OSX which has a openssl 
version that does not support TLS 1.2: 

OpenSSL 0.9.8zg 14 July 2015

Hope this helps resolve the issue.

Kind regards, 
Henrik
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
Please log in as guest with password guest if prompted

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