> [tm...@redhat.com - Wed Apr 25 12:10:34 2012]: > > On Wed, 2012-04-25 at 10:35 +0200, Andy Polyakov via RT wrote: > > more secure protocols. Trade-off. As 1.0.0 application is not in > > position to expect anything above TLS1.0, trade-off can as well be > > resolved in favor of interoperability. Note that there is not such > > trade-off in 1.0.1 application context, because 1.0.1 SSL_OP_ALL won't > > disable protocols above TLS1.0. > > I'd be in favor to moving the SSL_OP_NO_TLSv1_1 out of SSL_OP_ALL as of > 1.0.0 as application should not in general really care against which > openssl version _with stable ABI_ it is linked. And the capabilities > should be defined by the underlying installed library version and not > the version it was built against. Of course in case the application > needs to refer to API additions for the new functionality the situation > is different, but that is not the case of TLS1.1. > >
Yes and I think that's an important point. Applications should be able to take advantage of the new protocols without recompilation, if possible. If we have SSL_OP_ALL disable TLS 1.2 and 1.1 the main effect will be a significant reduction in TLS 1.2 and 1.1 deployment which would be a pity. Some very useful information is appearing as a result of more widespread use (and attempted use) of TLS 1.2 and OpenSSL's implementation is being very thoroughly tested. Longer term the whole "flags" technique of OpenSSL will need revising because we've run out of new flags. We could provide less ambiguous version support at the same time. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
