Contents

OpenSSL Client Conflicting Commands

Security 300 words 2 minutes

Prevent conflicting interactive commands when using OpenSSL client

OpenSSL Client is a helpful tool for carrying out diagnostics of servers using the SSL/TLS client protocols. It’s often used to evaluate SSL certificate status and negotiation. An example might be that you have configured your server to negotiate only using a strict set of ciphers and want to test and ensure that a client cannot use a more insecure cipher. The OpenSSL client has a set of basic and advanced Connected Commands. The naming is self explanatory, but these commands are used once a connection is established and allow you to interact with the server to perform requested operations. Examples include:

  • k - Send a key update message to the server (TLS 1.3 only)
  • R - Renegotiate the SSL session (TLSv1.2 and below only).

I was recently testing an Ubuntu server using the OpenSSL Client and hit an issue where the message I wanted to send conflicted with a Connected Command. This is the string I was sending:

1

kSkvUpMQ7lBYyCM4GBPvCvT1BfWRy0Dx

And there is the terminal response:

1
2
3

read R BLOCK
kSkvUpMQ7lBYyCM4GBPvCvT1BfWRy0Dx
KEYUPDATE

This took me a few minutes to work out and a read through the man doc. My arbitary string was conflicting with the KEYUPDATE Connected Command

There are a couple of solutions if you find yourself in this situation. Both are to pass additional parameters with during initial connection.

  1. The -nocommands parameter can be passed to disable interactive command letters. This allows strings to be passed without conflicting with Connected Commands e.g.
1

openssl s_client -connect localhost:31790 -nocommands
  1. I’ve found the -quiet parameter also works which inhibits printing of session and certificate information. and prevents the conflict occuring e.g.
1

openssl s_client -connect localhost:31790 -quiet

Hopefully this helps you if you find yourself in a similar situation.