Why can't I force a specific cipher with the openssl app with TLS 1.3?

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

Why can't I force a specific cipher with the openssl app with TLS 1.3?

Phil Neumiller
Here is my server script is:

PSK=63ef2024b1
openssl s_server -accept 4433 -tls1_3  -nocert -psk $PSK -ciphersuites
TLS_AES_256_GCM_SHA384

Here is the client:

PSK=63ef2024b1
openssl s_client -tls1_3 -psk $PSK -connect :4433  -ciphersuites
TLS_AES_256_GCM_SHA384

And here is the error:

Using default temp DH parameters
ACCEPT
ERROR
C0:65:9F:08:01:00:00:00:error:SSL routines::no suitable signature
algorithm:ssl/t1_lib.c:2810:
shutting down SSL
CONNECTION CLOSED

So why can't I force the usage of this cipher?  Why does it complain about
signature algorithms when I didn't specify any?





-----
Phillip Neumiller
Platform Engineering
Directstream, LLC
--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Phillip Neumiller Platform Engineering Directstream, LLC
Reply | Threaded
Open this post in threaded view
|

Re: Why can't I force a specific cipher with the openssl app with TLS 1.3?

Matt Caswell-2


On 14/11/2019 17:46, Phil Neumiller wrote:

> Here is my server script is:
>
> PSK=63ef2024b1
> openssl s_server -accept 4433 -tls1_3  -nocert -psk $PSK -ciphersuites
> TLS_AES_256_GCM_SHA384
>
> Here is the client:
>
> PSK=63ef2024b1
> openssl s_client -tls1_3 -psk $PSK -connect :4433  -ciphersuites
> TLS_AES_256_GCM_SHA384
>
> And here is the error:
>
> Using default temp DH parameters
> ACCEPT
> ERROR
> C0:65:9F:08:01:00:00:00:error:SSL routines::no suitable signature
> algorithm:ssl/t1_lib.c:2810:
> shutting down SSL
> CONNECTION CLOSED
>
> So why can't I force the usage of this cipher?  Why does it complain about
> signature algorithms when I didn't specify any?

All TLSv1.3 PSKs must have an associated hash algorithm. The "-psk"
arguument is the old TLSv1.2 way of doing PSKs. This works perfectly
fine in TLSv1.3 too but uses a default hash. Which is, as defined by the
TLSv1.3 spec, SHA-256. Because your chosen ciphersuite uses SHA-384 it
is not compatible with a SHA-256 PSK and therefore the PSK attempt fails.

Given that the attempt to use a PSK has failed OpenSSL then tries to
fallback to a full handshake. One of the first steps in that is to
select which certificate to use. It compares the set of signature
algorithms supplied by the client to see which ones are compatible with
the set of certificates configured for use on the server. In your case
you have specified "-nocert" so, because there are no certificates,
there are no suitable signature algorithms that match them.

In order to get this to work you need to do one of two things:

1) Change your ciphersuite to one that uses SHA-256

or

2) Use the "-psksession" argument instead of "-psk". That will require
you to have an SSL_SESSION object serialised into a file to read. That
SSL_SESSION needs to be set up as described on this page:

https://www.openssl.org/docs/man1.1.1/man3/SSL_set_psk_use_session_callback.html


Matt

Reply | Threaded
Open this post in threaded view
|

Re: Why can't I force a specific cipher with the openssl app with TLS 1.3?

Phil Neumiller
Hi Matt,

That works fine for 256 as you mentioned.  I trying to speak to a piece of
hardware that has one supported cipher, i.e. TLS_AES_256_GCM_SHA384.  I
tried the naive approach of

PSK=63ef2024b1
openssl s_server -accept 4433 -tls1_3  -nocert -psk $PSK -sigalgs RSA+SHA384
-ciphersuites TLS_AES_256_GCM_SHA384

And the server starts up as it does with ECDSA+SHA384.  However,

PSK=63ef2024b1
openssl s_client -tls1_3 -psk $PSK -connect :4433 -sigalgs RSA+SHA384
-ciphersuites TLS_AES_256_GCM_SHA384

Fails with invalid signature algorithm - which from your post I'm
interpreting as I need a session file.  The link you mentioned in your post
only describes the problem from the call back or API perspective and I was
really hoping to get this to work with something like:

openssl s_server -session_file fname ...

But when I follow that link it doesn't describe how to create the file.  I
seem to be misinterpreting something.

Thanks,

Phil




-----
Phillip Neumiller
Platform Engineering
Directstream, LLC
--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Phillip Neumiller Platform Engineering Directstream, LLC
Reply | Threaded
Open this post in threaded view
|

Re: Why can't I force a specific cipher with the openssl app with TLS 1.3?

Matt Caswell-2


On 14/11/2019 22:30, Phil Neumiller wrote:

> Hi Matt,
>
> That works fine for 256 as you mentioned.  I trying to speak to a piece of
> hardware that has one supported cipher, i.e. TLS_AES_256_GCM_SHA384.  I
> tried the naive approach of
>
> PSK=63ef2024b1
> openssl s_server -accept 4433 -tls1_3  -nocert -psk $PSK -sigalgs RSA+SHA384
> -ciphersuites TLS_AES_256_GCM_SHA384
>
> And the server starts up as it does with ECDSA+SHA384.  However,
>
> PSK=63ef2024b1
> openssl s_client -tls1_3 -psk $PSK -connect :4433 -sigalgs RSA+SHA384
> -ciphersuites TLS_AES_256_GCM_SHA384
>
> Fails with invalid signature algorithm - which from your post I'm
> interpreting as I need a session file.  The link you mentioned in your post
> only describes the problem from the call back or API perspective and I was
> really hoping to get this to work with something like:
>
> openssl s_server -session_file fname ...
>
> But when I follow that link it doesn't describe how to create the file.  I
> seem to be misinterpreting something.

Both s_client and s_server have the option of taking a psk session file
on the command line using the "-psk_session" option (sorry I think I
referred to this as "-psksession" in my previous email - without the
underscore) - but you need to have a session file already in existence
in order for that to work.

It might be nice if we added a new option "-pskmd" or similar which
enabled you to specify the md from the command line without having to
have a session file first. However that isn't currently possible.

Ideally you would create your session file in the manner described on
the man page I linked to. However that does require some C programming.

There is a "hack" you can use to generate a session file from the
command line. However this will generate a new random PSK so if you have
a specific value already that you need to use then it won't help. I also
wouldn't necessarily recommend this approach for production use - but
for testing purposes it should be fine. You'll need a server certificate
and server key in order to generate the file (any certificate including
self-signed will be just fine).

Run an s_server instance like this, specifying your cert/key:

$ openssl s_server -ciphersuites TLS_AES_256_GCM_SHA384 -cert server.pem
-key server.pem

Now connect via s_client:

$ openssl s_client -ciphersuites TLS_AES_256_GCM_SHA384 -sess_out
psksession.pem

This will generate you a session file called psksession.pem compatible
with the TLS_AES_256_GCM_SHA384 ciphersuite.

Now you should be able to use it as a PSK:

$ openssl s_server -psk_session psksession.pem -nocert -ciphersuites
TLS_AES_256_GCM_SHA384
$ openssl s_client -ciphersuites TLS_AES_256_GCM_SHA384 -psk_session
psksession.pem


However if you need to use a a specific PSK value then, at the moment,
the only real choice is to programmatically create the session file.

Matt
Reply | Threaded
Open this post in threaded view
|

Re: Why can't I force a specific cipher with the openssl app with TLS 1.3?

Viktor Dukhovni
> On Nov 15, 2019, at 4:25 AM, Matt Caswell <[hidden email]> wrote:
>
> It might be nice if we added a new option "-pskmd" or similar which
> enabled you to specify the md from the command line without having to
> have a session file first. However that isn't currently possible.

With a saved session there may actually be enough key material to
arrive at non-trivial security.  As it stands, the OP wrote:

> PSK=63ef2024b1
> openssl s_client -tls1_3 -psk $PSK -connect :4433  -ciphersuites TLS_AES_256_GCM_SHA384

That 40-bit PSK does not provide much security.  I would hope that
"in real life" (simple tests aside) the PSKs will have non-trivial
entropy.

--
        Viktor.