On Thu, 4 Dec 2014 10:57:11 +0100 Kurt Roeckx wrote: > > It seems *TLS*_VERSION constants are meant to be used to set > > minimum / maximum. A drawback of such approach is that > > applications need to be recompiled and/or modified when OpenSSL is > > updated with support for newer protocol version, if use of the new > > version is to be controlled via this API. > > So if I understand you right, say that we make a release that > support up to TLS 1.2 and your application is compiled against > that. That would mean it will only know how to set the minimum > and maximum to TLS 1.2. If I then add support for TLS 1.3 there > would be no way to say that TLS 1.3 should be the minimum without > adding support for that in the application?
Right. Look at it with your Debian openssl packages maintainer hat on - how many packages need to be modified to support 1.3? > > SSLProtocolMin "TLSv1.0" > > > > instead of > > > > SSLProtocol all -SSLv2 -SSLv3 > > > > Or maybe have a way to control protocol versions via cipher suite > > string. Similar to what GnuTLS does with its priority string, which > > can set ciphers, protocol versions, etc. > > I was thinking about that too before. We already have SECLEVEL in > there now (in 1.0.2). What is the SECLEVEL you refer to? I had a quick look at SSL_CONF API pointed out by Stephen. I see it can do what I asked for (not the min/max way, but the httpd-like way). -- Tomas Hoger ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
