2016-03-28 12:59 GMT+03:00 Mark Thomas <[email protected]>:
> On 28/03/2016 10:51, [email protected] 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: [email protected]
For additional commands, e-mail: [email protected]