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

Reply via email to