maskit opened a new pull request, #9667: URL: https://github.com/apache/trafficserver/pull/9667
I found an incompatibility between OpenSSL and BoringSSL. If `valid_tls_versions_in` has `[TLSv1, TLSv1_2, TLSv1_3]` (note that `TLSv1_1` isn't in the list), BoringSSL only allows TLSv1 where OpenSSL allows all the three versions. It sounds like a bug but it's actually not. https://boringssl.googlesource.com/boringssl/+/86ada1ea2f51ff41baa2919337e5d721bd27f764/ssl/ssl_versions.cc#225 > // If there is a disabled version after the first enabled one, all versions // after it are implicitly disabled. And I also found that the way (API) we currently use to specify available TLS versions is deprecated. The old way allow us to specify versions individually (like above), but the new way only allows us to specify a range of versions. Old: https://www.openssl.org/docs/man3.1/man3/SSL_CTX_set_options.html https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_OP_NO_TLSv1 New: https://www.openssl.org/docs/man3.1/man3/SSL_CTX_set_min_proto_version.html https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_set_min_proto_version Since the old way is no longer supported by SSL libraries, we should deprecate the current way and only allow ATS users to specify a range. ---- This adds these new settings: ``` records.yaml: proxy.config.ssl.server.version.min proxy.config.ssl.server.version.max proxy.config.ssl.client.version.min proxy.config.ssl.client.version.max sni.yaml: valid_tls_version_min_in valid_tls_version_max_in ``` and deprecates these settings: ``` records.yaml: proxy.config.ssl.TLSv1 proxy.config.ssl.TLSv1_1 proxy.config.ssl.TLSv1_2 proxy.config.ssl.TLSv1_3 proxy.config.ssl.client.TLSv1 proxy.config.ssl.client.TLSv1_1 proxy.config.ssl.client.TLSv1_2 proxy.config.ssl.client.TLSv1_3 sni.yaml: valid_tls_versions_in ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
