Testing TLS 1.0 with OpenSSL master

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Testing TLS 1.0 with OpenSSL master

John Baldwin
Sadly, I need to be able to test some KTLS changes I have in FreeBSD
that support legacy clients still using TLS 1.0.  After seeing the note
in CHANGES.md about TLS 1.0 signature algs no longer being permitted
in the default security level, I tried using '-auth_level=0' to lower
the security level, but this didn't work for either the client or
server.

Adding '@SECLEVEL=0' to the ciphers explicitly does work for the
server, but I still see an odd regression with the client.  Specifically,
if you run the following server (OpenSSL 1.1.1)

openssl s_server -cert cert.pem -key cert.key -accept 443 -msg -www -tls1

and then use the following OpenSSL 3.0.0 client:

env OPENSSL_CONF=noetm.cnf openssl s_client -host oe1 -port 443 -msg -tls1 -cipher 'AES256-SHA@SECLEVEL=0'

(where noetm.conf is a config file to disable ETM and force the use of MTE)

then the connection hangs after the handshake.

Last bits of server output:

>>> TLS 1.0, Handshake [length 00aa], NewSessionTicket
    04 00 00 a6 00 00 1c 20 00 a0 b8 1e 37 f3 ab 34
    1f 42 05 b0 cf 7c 86 91 2d 20 10 99 e3 8c 61 f1
    7a f7 0a d4 1a fb e8 11 76 b2 66 3a 0e bd 73 54
    cf e7 f5 6c 01 f2 c6 bd 17 b4 0a 42 c0 b5 d1 87
    22 ae 21 f0 2a 6a 79 3c 2e 33 71 8b e2 c8 ff 6c
    8c 2a 34 58 ca 2d e6 52 7b 0a 3a 17 1b 51 3d 8d
    de f0 b9 0f 6b 4c 94 fd 49 fb 74 fa 0c 9e b2 32
    98 dc 28 ca 66 01 ba 1c 24 a7 80 38 65 ac dd dc
    7c 9f 1a 16 73 0f 57 51 73 d4 17 35 5e 71 1c 32
    10 6b b7 b6 1f 8b 7b e6 88 c2 05 73 5f 95 26 50
    6a 08 7f 04 66 1e b8 5f db 51
>>> ??? [length 0005]
    14 03 01 00 01
>>> TLS 1.0, ChangeCipherSpec [length 0001]
    01
>>> ??? [length 0005]
    16 03 01 00 30
>>> TLS 1.0, Handshake [length 0010], Finished
    14 00 00 0c 35 b9 fa 86 7f 32 75 62 71 c5 16 a3

Last bits of client output:

<<< TLS 1.0, Handshake [length 00aa], NewSessionTicket
    04 00 00 a6 00 00 1c 20 00 a0 b8 1e 37 f3 ab 34
    1f 42 05 b0 cf 7c 86 91 2d 20 10 99 e3 8c 61 f1
    7a f7 0a d4 1a fb e8 11 76 b2 66 3a 0e bd 73 54
    cf e7 f5 6c 01 f2 c6 bd 17 b4 0a 42 c0 b5 d1 87
    22 ae 21 f0 2a 6a 79 3c 2e 33 71 8b e2 c8 ff 6c
    8c 2a 34 58 ca 2d e6 52 7b 0a 3a 17 1b 51 3d 8d
    de f0 b9 0f 6b 4c 94 fd 49 fb 74 fa 0c 9e b2 32
    98 dc 28 ca 66 01 ba 1c 24 a7 80 38 65 ac dd dc
    7c 9f 1a 16 73 0f 57 51 73 d4 17 35 5e 71 1c 32
    10 6b b7 b6 1f 8b 7b e6 88 c2 05 73 5f 95 26 50
    6a 08 7f 04 66 1e b8 5f db 51
<<< ??? [length 0005]
    14 03 01 00 01
<<< ??? [length 0005]
    16 03 01 00 30

I get the same hang if I run the client against a 'master' server
(the 'master' server requires an explicit -cipher as well).

So I guess two questions:

1) Is 'auth_level' supposed to work for this?  The CHANGES.md change
   references SSL_CTX_set_security_level and openssl(1) claims that
   '-auth_level' changes this?  Is the CHANGES.md entry wrong and only
   SECLEVEL=0 for the ciphers work by design?

2) The hang when using a 'master' client seems like a regression?

--
John Baldwin
Reply | Threaded
Open this post in threaded view
|

Re: Testing TLS 1.0 with OpenSSL master

Matt Caswell-2


On 17/08/2020 18:55, John Baldwin wrote:
> 1) Is 'auth_level' supposed to work for this?  The CHANGES.md change
>    references SSL_CTX_set_security_level and openssl(1) claims that
>    '-auth_level' changes this?  Is the CHANGES.md entry wrong and only
>    SECLEVEL=0 for the ciphers work by design?

openssl(1) says this about auth_level:

"Set the certificate chain authentication security level to I<level>.
The authentication security level determines the acceptable signature
and public key strength when verifying certificate chains."

However, the problem you are seeing is about *handshake* signatures
using SHA1 - so auth_level is not appropriate.


>
> 2) The hang when using a 'master' client seems like a regression?
>

Fix for this issue here:

https://github.com/openssl/openssl/pull/12670

Matt

Reply | Threaded
Open this post in threaded view
|

Re: Testing TLS 1.0 with OpenSSL master

John Baldwin
On 8/18/20 9:49 AM, Matt Caswell wrote:

>
>
> On 17/08/2020 18:55, John Baldwin wrote:
>> 1) Is 'auth_level' supposed to work for this?  The CHANGES.md change
>>    references SSL_CTX_set_security_level and openssl(1) claims that
>>    '-auth_level' changes this?  Is the CHANGES.md entry wrong and only
>>    SECLEVEL=0 for the ciphers work by design?
>
> openssl(1) says this about auth_level:
>
> "Set the certificate chain authentication security level to I<level>.
> The authentication security level determines the acceptable signature
> and public key strength when verifying certificate chains."
>
> However, the problem you are seeing is about *handshake* signatures
> using SHA1 - so auth_level is not appropriate.

I think what I found confusing is that later in the text it says this:

"See SSL_CTX_set_security_level(3) for the definitions of the available
 levels."

so I had assumed it was calling that function.

>> 2) The hang when using a 'master' client seems like a regression?
>>
>
> Fix for this issue here:
>
> https://github.com/openssl/openssl/pull/12670

Thanks!

--
John Baldwin
Reply | Threaded
Open this post in threaded view
|

Re: Testing TLS 1.0 with OpenSSL master

Kurt Roeckx
On Mon, Aug 24, 2020 at 01:38:41PM -0700, John Baldwin wrote:

> On 8/18/20 9:49 AM, Matt Caswell wrote:
> >
> >
> > On 17/08/2020 18:55, John Baldwin wrote:
> >> 1) Is 'auth_level' supposed to work for this?  The CHANGES.md change
> >>    references SSL_CTX_set_security_level and openssl(1) claims that
> >>    '-auth_level' changes this?  Is the CHANGES.md entry wrong and only
> >>    SECLEVEL=0 for the ciphers work by design?
> >
> > openssl(1) says this about auth_level:
> >
> > "Set the certificate chain authentication security level to I<level>.
> > The authentication security level determines the acceptable signature
> > and public key strength when verifying certificate chains."
> >
> > However, the problem you are seeing is about *handshake* signatures
> > using SHA1 - so auth_level is not appropriate.
>
> I think what I found confusing is that later in the text it says this:
>
> "See SSL_CTX_set_security_level(3) for the definitions of the available
>  levels."
>
> so I had assumed it was calling that function.

It calls X509_VERIFY_PARAM_set_auth_level(), which also says to
look at SSL_CTX_set_security_level().

If you call SSL_CTX_set_security_level(),
X509_VERIFY_PARAM_set_auth_level() will be called with the same
value.


Kurt