Patch to set TLS maximum version

[Alan DeKok]

  Found as part of TLS 1.3 testing.

  On a related note, I've been adding automated tests to FreeRADIUS for the various EAP methods, and the various TLS versions.  If I enabled one TLS version via "tls_disable_tlsv1_0=0" and disabled all others, then eapol_test would always use TLS 1.3!  The behavior was the same for TLS 1.0 and TLS 1.1.  But doing the same thing for TLS 1.2 was OK.

  It seems like an issue in OpenSSL.  I'm summarizing it here so that other people don't have the same problems I did.

  The code in src/crypto/tls_openssl.c calls:

	SSL_set_options(ssl, ...);

  to enable / disable the TLS versions.  Then it *also* calls SSL_set_min_proto_version(),  and with this patch it also calls SSL_set_max_proto_version().  That's all well and good for TLS 1.2, but it doesn't work for TLS 1.0 and TLS 1.1.

  However... calling *either* SSL_set_min_proto_version() or SSL_set_max_proto_version(), seems to over-ride the earlier calls to SSL_set_option().  Even worse, whatever version was set via SSL_set_min_proto_version() is *also* ignored, and OpenSSL always proposed TLS 1.3.

  That behavior seems bad.  :(  My short-term work-around locally is to just comment out the code in tls_openssl.c which calls SSL_set_min_proto_version().  So that only SSL_set_options() is called.  It then works.

  This is on OSX with OpenSSL 1.1.0 installed from homebrew.  I haven't checked other versions of OpenSSL yet.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Set-maximum-TLS-version-too.patch
Type: application/octet-stream
Size: 1676 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20210211/c18ae7b5/attachment.obj>