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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
