You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Garrison, Jim (ETW)" <Ji...@nike.com> on 2012/06/14 00:56:19 UTC
Newer SSL libraries and TLSv1.2 incompatibilities
Regarding my question in the thread titled "When connecting to an https server force use of TLS or SSLv3?".
I asked that before I fully understood the problem, which is actually due to a backwards incompatibility in the newest OpenSSL libraries (1.0.1c) used by Subversion. Essentially, the newest client library can cause older servers to hang when it sends a TLSv1.2 handshake.
The release notes for OpenSSL 1.0.1c contain (changes between 1.0.1 and 1.0.1a):
*) Workarounds for some broken servers that "hang" if a client hello
record length exceeds 255 bytes.
1. Do not use record version number > TLS 1.0 in initial client
hello: some (but not all) hanging servers will now work.
2. If we set OPENSSL_MAX_TLS1_2_CIPHER_LENGTH this will truncate
the number of ciphers sent in the client hello. This should be
set to an even number, such as 50, for example by passing:
-DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 to config or Configure.
Most broken servers should now work.
3. If all else fails setting OPENSSL_NO_TLS1_2_CLIENT will disable
TLS 1.2 client support entirely.
Is there any way, other than completely rebuilding svn locally, to use these workarounds?
Re: Newer SSL libraries and TLSv1.2 incompatibilities
Posted by Daniel Shahaf <da...@elego.de>.
Philip Martin wrote on Fri, Jun 15, 2012 at 16:32:13 +0100:
> Daniel Shahaf <da...@elego.de> writes:
>
> > Garrison, Jim (ETW) wrote on Thu, Jun 14, 2012 at 10:49:47 -0700:
> >>
> >> This is going to cause major headaches for a lot of people. OpenSSL
> >> client versions 1.0.1 and later can and will cause earlier server
> >> versions to hang at CLIENT HELLO. There are options in the OpenSSL
> >> code to tailor the client behavior to avoid this, but they require
> >> the client applications (i.e. subversion) to support setting these
> >> options. For example
> >>
> >> ctx = SSL_CTX_new(...);
> >> SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_2);
> >>
> >> What's the possibility of getting an enhancement to subversion to support this in its server configuration?
> >
> > Haven't read everything, but Subversion does not call SSL_CTX_new() at
> > all; its dependencies, libneon and/or libserf, do.
>
> Both serf and neon do:
>
> SSL_CTX_set_options(ctx, SSL_OP_ALL);
>
> neon provides ne_ssl_context_set_flag() but it can only be used to
> set/clear SSL_OP_NO_SSLv2.
I assume that's with the latest stable release of each?
Re: Newer SSL libraries and TLSv1.2 incompatibilities
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <da...@elego.de> writes:
> Garrison, Jim (ETW) wrote on Thu, Jun 14, 2012 at 10:49:47 -0700:
>>
>> This is going to cause major headaches for a lot of people. OpenSSL
>> client versions 1.0.1 and later can and will cause earlier server
>> versions to hang at CLIENT HELLO. There are options in the OpenSSL
>> code to tailor the client behavior to avoid this, but they require
>> the client applications (i.e. subversion) to support setting these
>> options. For example
>>
>> ctx = SSL_CTX_new(...);
>> SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_2);
>>
>> What's the possibility of getting an enhancement to subversion to support this in its server configuration?
>
> Haven't read everything, but Subversion does not call SSL_CTX_new() at
> all; its dependencies, libneon and/or libserf, do.
Both serf and neon do:
SSL_CTX_set_options(ctx, SSL_OP_ALL);
neon provides ne_ssl_context_set_flag() but it can only be used to
set/clear SSL_OP_NO_SSLv2.
--
Philip
Re: Newer SSL libraries and TLSv1.2 incompatibilities
Posted by Daniel Shahaf <da...@elego.de>.
Garrison, Jim (ETW) wrote on Thu, Jun 14, 2012 at 10:49:47 -0700:
> > -----Original Message-----
> > From: Garrison, Jim (ETW) [mailto:Jim.Garrison@nike.com]
> > Sent: Wednesday, June 13, 2012 3:56 PM
> > To: users@subversion.apache.org
> > Subject: Newer SSL libraries and TLSv1.2 incompatibilities
> >
> > Regarding my question in the thread titled "When connecting to an https
> > server force use of TLS or SSLv3?".
> >
> > I asked that before I fully understood the problem, which is actually
> > due to a backwards incompatibility in the newest OpenSSL libraries
> > (1.0.1c) used by Subversion. Essentially, the newest client library can
> > cause older servers to hang when it sends a TLSv1.2 handshake.
> >
> > The release notes for OpenSSL 1.0.1c contain (changes between 1.0.1 and
> > 1.0.1a):
> >
> > *) Workarounds for some broken servers that "hang" if a client hello
> > record length exceeds 255 bytes.
> >
> > 1. Do not use record version number > TLS 1.0 in initial client
> > hello: some (but not all) hanging servers will now work.
> > 2. If we set OPENSSL_MAX_TLS1_2_CIPHER_LENGTH this will truncate
> > the number of ciphers sent in the client hello. This should be
> > set to an even number, such as 50, for example by passing:
> > -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 to config or Configure.
> > Most broken servers should now work.
> > 3. If all else fails setting OPENSSL_NO_TLS1_2_CLIENT will disable
> > TLS 1.2 client support entirely.
> >
> > Is there any way, other than completely rebuilding svn locally, to use
> > these workarounds?
>
> Please see http://rt.openssl.org/Ticket/Display.html?id=2771&user=guest&pass=guest
>
> This is going to cause major headaches for a lot of people. OpenSSL client versions 1.0.1 and later can and will cause earlier server versions to hang at CLIENT HELLO. There are options in the OpenSSL code to tailor the client behavior to avoid this, but they require the client applications (i.e. subversion) to support setting these options. For example
>
> ctx = SSL_CTX_new(...);
> SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_2);
>
> What's the possibility of getting an enhancement to subversion to support this in its server configuration?
Haven't read everything, but Subversion does not call SSL_CTX_new() at
all; its dependencies, libneon and/or libserf, do.
RE: Newer SSL libraries and TLSv1.2 incompatibilities
Posted by "Garrison, Jim (ETW)" <Ji...@nike.com>.
> -----Original Message-----
> From: Garrison, Jim (ETW) [mailto:Jim.Garrison@nike.com]
> Sent: Wednesday, June 13, 2012 3:56 PM
> To: users@subversion.apache.org
> Subject: Newer SSL libraries and TLSv1.2 incompatibilities
>
> Regarding my question in the thread titled "When connecting to an https
> server force use of TLS or SSLv3?".
>
> I asked that before I fully understood the problem, which is actually
> due to a backwards incompatibility in the newest OpenSSL libraries
> (1.0.1c) used by Subversion. Essentially, the newest client library can
> cause older servers to hang when it sends a TLSv1.2 handshake.
>
> The release notes for OpenSSL 1.0.1c contain (changes between 1.0.1 and
> 1.0.1a):
>
> *) Workarounds for some broken servers that "hang" if a client hello
> record length exceeds 255 bytes.
>
> 1. Do not use record version number > TLS 1.0 in initial client
> hello: some (but not all) hanging servers will now work.
> 2. If we set OPENSSL_MAX_TLS1_2_CIPHER_LENGTH this will truncate
> the number of ciphers sent in the client hello. This should be
> set to an even number, such as 50, for example by passing:
> -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 to config or Configure.
> Most broken servers should now work.
> 3. If all else fails setting OPENSSL_NO_TLS1_2_CLIENT will disable
> TLS 1.2 client support entirely.
>
> Is there any way, other than completely rebuilding svn locally, to use
> these workarounds?
Please see http://rt.openssl.org/Ticket/Display.html?id=2771&user=guest&pass=guest
This is going to cause major headaches for a lot of people. OpenSSL client versions 1.0.1 and later can and will cause earlier server versions to hang at CLIENT HELLO. There are options in the OpenSSL code to tailor the client behavior to avoid this, but they require the client applications (i.e. subversion) to support setting these options. For example
ctx = SSL_CTX_new(...);
SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_2);
What's the possibility of getting an enhancement to subversion to support this in its server configuration?