2016-03-28 12:59 GMT+03:00 Mark Thomas <ma...@apache.org>: > On 28/03/2016 10:51, ma...@apache.org wrote: >> Author: markt >> Date: Mon Mar 28 09:51:14 2016 >> New Revision: 1736849 >> >> URL: http://svn.apache.org/viewvc?rev=1736849&view=rev >> Log: >> TLSv1 is not exactly the same as SSLv3. Some ciphers are only available for >> TLSv1. > > Hmm. As far as I can tell, OpenSSL 1.1.x and OpenSSL 1.0.x have a > different view on what TLSv1 means. > > It looks like: > 1.1.x treats it as those ciphers that require TLSv1 > 1.0.x treats it as an alias for SSLv3. > > Currently 9.0.x is aligned with 1.1.x and 8.0.x is aligned with 1.0.x. > > I'm going to align 8.5.x with 1.1.x. > > Experience tells me this stuff is easy to get wrong so a second pair of > eyes would be appreciated.
1. I am not sure whether using two numbers as OpenSSL version is correct. Current stable branches of OpenSSL are 1.0.1 and 1.0.2. (support for 1.0.0 ended on 31st December 2015) 2. Technically, I think it is more correct to align 8.5.x with 1.0.2. There have not been any stable release of OpenSSL 1.1.0 yet. The latest is beta 1 (pre-release 4) issued on 16-Mar-2016. Once there is a release, I think we will wait several (3?) months before releasing a TCNative with that version of OpenSSL, TCNative 1.2.5 was built with OpenSSL 1.0.2g. 3. I tried to look through source code of old openssl-1.0.2d sources (dated Jul 2015) on whether "TLSv1" is actually a synonym for "SSLv3". I do not see it. Places that it is mentioned CHANGES file: Changes between 0.9.0b and 0.9.1b [not released] ... *) Support the string "TLSv1" for all TLS v1 ciphers. [Eric A. Young] ssl/ssl.h # define SSL_TXT_SSLV2 "SSLv2" # define SSL_TXT_SSLV3 "SSLv3" # define SSL_TXT_TLSV1 "TLSv1" # define SSL_TXT_TLSV1_1 "TLSv1.1" # define SSL_TXT_TLSV1_2 "TLSv1.2" ssl/ssl_ciph.c /* protocol version aliases */ {0, SSL_TXT_SSLV2, 0, 0, 0, 0, 0, SSL_SSLV2, 0, 0, 0, 0}, {0, SSL_TXT_SSLV3, 0, 0, 0, 0, 0, SSL_SSLV3, 0, 0, 0, 0}, {0, SSL_TXT_TLSV1, 0, 0, 0, 0, 0, SSL_TLSV1, 0, 0, 0, 0}, {0, SSL_TXT_TLSV1_2, 0, 0, 0, 0, 0, SSL_TLSV1_2, 0, 0, 0, 0}, ssl/ssl_locl.h /* Bits for algorithm_ssl (protocol version) */ # define SSL_SSLV2 0x00000001UL # define SSL_SSLV3 0x00000002UL # define SSL_TLSV1 SSL_SSLV3/* for now */ # define SSL_TLSV1_2 0x00000004UL ========== I master branch at https://github.com/openssl/openssl/ ssl/ssl_ciph.c /* protocol version aliases */ {0, SSL_TXT_SSLV3, 0, 0, 0, 0, 0, SSL3_VERSION, 0, 0, 0, 0, 0, 0, 0}, {0, SSL_TXT_TLSV1, 0, 0, 0, 0, 0, TLS1_VERSION, 0, 0, 0, 0, 0, 0, 0}, {0, "TLSv1.0", 0, 0, 0, 0, 0, TLS1_VERSION, 0, 0, 0, 0, 0, 0, 0}, {0, SSL_TXT_TLSV1_2, 0, 0, 0, 0, 0, TLS1_2_VERSION, 0, 0, 0, 0, 0, 0, 0}, So it looks that indeed 1.0.2 uses the same numerical value and there was a change in OpenSSL master branch, The commit that changed ssl_ciph.c is https://github.com/openssl/openssl/commit/3eb2aff40116ecceab847c895cbf02cdb075d194#diff-3e095c8fd6cb53927997c3e898fc7a74 I wonder why their changelog does not mention this behaviour change, http://openssl.org/news/changelog.html I have never run 1.1.0, and I wonder whether the change is actually noticeable: whether it changes output of OpenSSL ciphers command. If it has a noticeable effect, not mentioning it looks like a bug. 4. One option is to deprecate/remove support for value "TLSv1" in cipher specification, due to its ambiguity. OpenSSL 1.0.2 users can use "SSLv3" which is a synonym. OpenSSL 1.1.0 users can use "TLSv1.0", which is new in 1.1.0. http://openssl.org/docs/manmaster/apps/ciphers.html (man page for master version) lists "TLSv1.0". It does not list "TLSv1" among values. http://openssl.org/docs/man1.0.2/apps/ciphers.html (man page for 1.0.2 version) lists "TLSv1". Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org