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

Matt Caswell matt at openssl.org
Fri Nov 15 09:25:10 UTC 2019



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


More information about the openssl-users mailing list