Bug#766929: SSL handshake failed (fail to connect to sites that only support TLS1.0)

[Kurt Roeckx]

On Mon, Oct 27, 2014 at 02:31:48AM -0700, Troy Sankey wrote:
> On 2014-10-27 00:44:31 -0700, Laurent Bigonville wrote:
> > As you can see there is a redirection, to shb.ais.ucla.edu.
> > 
> > Running both openssl s_client and gnutls-cli on this URL gives me an
> > error. Forcing openssl to use TLS1.0 works. (Not sure how to do the
> > same with gnutls-cli though).
> 
>   $ gnutls-cli --priority "NORMAL:-VERS-TLS1.2:-VERS-TLS1.1" shb.ais.ucla.edu
> 
> This disables TLS1.2 and TLS1.1, forcing it to use TLS1.0.  It
> connects successfully only with TLS1.0.
> 
> It seems like all those browsers I tested actually *can* connect
> successfully to be.my.ucla.edu, but they fail when redirecting to
> shb.ais.ucla.edu which only supports TLS1.0.

As I understand it, the problem is with shb.ais.ucla.edu.  It is
"intolerant" to TLS 1.2, but not to 1.1.  That means if you send a
client hello message which indicates that the highest supported
version is TLS 1.2 it just closes the connection.  It should just
be returning it's highest version which would be TLS 1.0.

So the software on shb.ais.ucla.edu is broken.  This is known
problem with some sites.  What some browsers do in that case is to
do a "fallback" where they send a lower supported version in the
client hello and hope that it works now.  With s_client you can do
that with for instance -no_tls1_2, in which case it will indicate
it only supports up to TLS 1.1, and then it works.

But if you're going to implement something like that you need to
be aware that that fallback behaviour can be abused to force you
to downgrade to an older TLS version while both ends support a
newer version.  There is a new draft that allows you to signal
that you did this fallback.  At least openssl has support for that
in the current versions in the archive.  This of course requires
that both sides know about that signal.


Kurt