TLS 1.1 and TLS 1.2 Support - use SSLv23_method() not TLSv1_method()

[Jouni Malinen]

On Wed, Nov 05, 2014 at 01:30:33PM +0000, Nick Lowe wrote:
> Please can tls_openssl.c be corrected so that it calls SSLv23_method()
> and not TLSv1_method() allowing TLS 1.1 and TLS 1.2 to be used?

I'm pretty sure I've testing OpenSSL TLS v1.1 implementation against the
internal TLS implementation, but cannot really remember how exactly that
happened taken into account the strange TLSv1_method() behavior..
Anyway, the current behavior with OpenSSL 1.0.1 did indeed seem to limit
negotiation to TLS v1.0.

> TLSv1_method() enforces that TLS 1.0 is always used so it is the
> incorrect method to call.

Well, what is "incorrect" depends on what you want to see as the
behavior.. Updating OpenSSL has resulted in number of interoperability
issues in the past due to pretty bad TLS implementations used on the
server side.

> See: https://www.openssl.org/docs/ssl/SSL_CTX_new.html
> 
> It should just be as simple as:
> 
> -    ssl = SSL_CTX_new(TLSv1_method());
> +    ssl = SSL_CTX_new(SSLv23_method());

It is not that simple. This change on its own would open an undesirable
security flaw. SSLv2 and SSLv3 shall not be enabled for EAP-TLS. In
addition to this, there are unfortunately authentication servers that
have significant interoperability issues with any TLS changes.. That
said, we do now have possibility of using tls_disable_tlsv1_1=1 and
tls_disable_tlsv1_2=1 in the phase1 network parameter to allow the newer
versions to be disabled.

I'll change tls_openssl.c to enable the newer protocols without
allowing the older ones to be used. This was already the case with the
internal TLS implementation and GnuTLS, so it sounds fine to make the
default behavior with OpenSSL match that even if that will trigger some
interoperability issues (that can be worked around with the phase1
parameters).

-- 
Jouni Malinen                                            PGP id EFC895FA