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
