Measure TLS Handshake and Session Reuse with openssl s_time

By the end of this guide you will have a repeatable openssl s_time command for measuring an SSL/TLS endpoint, and a second run that shows the effect of reusing sessions. The command counts connections and reports bytes read; it is a timing probe, not a general HTTP load tester.

Allow about 10 minutes. You need the OpenSSL command line tools and a host and port that you are authorised to test. No elevated privileges are needed for the examples. Benchmarking a third-party service without permission can look like abuse, so use a service you operate or a local test server.

1. Check the installed command

The installed binary is OpenSSL 3.6.1 on this machine. The local manpage is labelled OpenSSL 3.0.13, so use the command's own help for the options and defaults actually exposed by the installed binary:

$ openssl version
OpenSSL 3.6.1 27 Jan 2026
$ openssl s_time -help

Look for -time, which defaults to 30 seconds, and -connect, whose default is localhost:4433. Set both explicitly in a measurement so an omitted argument does not send the test to an unexpected local service.

2. Run a short handshake-only measurement

Start with a short run that does not request a page. Replace example.net:443 with your authorised endpoint:

$ openssl s_time -connect example.net:443 -time 10 -new

-new measures new connections. The command prints a progress stream followed by a summary resembling this:

Collecting connection statistics for 10 seconds
...
123 connections in 0.98s; 125.51 connections/user sec, bytes read 0
123 connections in 11 real seconds, 0 bytes read per connection

The exact counts and durations vary with the host, network path, CPU and server load. With no -www option, the measurement covers the TLS handshake but does not transfer an application payload. This is useful when you want to separate connection setup from response handling.

If the endpoint needs a name for virtual hosting, this command does not provide the full set of controls available in openssl s_client. Confirm the endpoint and protocol requirements with the service owner before interpreting a failed handshake as a performance result.

3. Include a known page and bound the test

Use -www when the test should fetch an HTTP page as part of each connection. A value of / requests the server's default page:

$ openssl s_time -connect example.net:443 -www / -time 10 -new

The summary now includes a non-zero byte count when the server returns data. The transfer size can vary if the page is dynamic, compressed differently or changed during the run. For a stable comparison, use a small endpoint whose response is controlled by you and record the URL, test duration, protocol options and server state beside the result.

Do not use a long duration while you are still checking syntax. The default is 30 seconds, and a busy endpoint may process many connections in that period. Increase the duration only after you have permission and a reason to collect more samples.

4. Compare new sessions with reused sessions

Run the same request with -reuse:

$ openssl s_time -connect example.net:443 -www / -time 10 -reuse

This tests whether the connection can reuse the same session ID. The output begins with a line such as Now timing with session id reuse. and uses r characters to show reuse attempts. Compare the connection rate and bytes per connection with the matching -new run, but keep the test conditions the same.

If neither -new nor -reuse is specified, this version runs both tests in sequence. That default is easy to miss when reading a short command copied from a shell history. Use one option when you need one clearly labelled measurement, or specify both as separate commands when you want an uncomplicated comparison.

5. Make certificate behaviour explicit

For a normal public HTTPS service, leave certificate verification out of this performance probe unless verification is part of the question. To turn it on, provide a maximum chain depth:

$ openssl s_time -connect example.net:443 -www / -time 10 -new -verify 5

The manpage records a sharp edge: verification continues after errors, and a failed server certificate check does not itself make the connection fail. Treat the reported timing as invalid until you inspect the diagnostic output and separately verify the certificate with a tool suited to that investigation.

For a private service, select the trust source deliberately:

$ openssl s_time -connect service.example.test:443 -www / -time 10 -new \
    -CAfile /path/to/test-ca.pem

-cafile is an obsolete synonym for -CAfile in OpenSSL 3. The -cert and -key options are for a client certificate and private key, not for trusting the server. A client certificate is used only when the server requests one, so merely adding -cert does not prove that mutual TLS is configured correctly.

Never paste a private key into an article, shell transcript or shared ticket. If a key has been exposed, stop the test and rotate it according to the service's incident process.

6. Verify a local test without touching a real service

For a safe smoke test, run an OpenSSL test server with a temporary certificate, then point s_time at it. The server command is deliberately local and does not require root:

$ openssl s_server -accept 9443 \
    -cert /tmp/s-time-cert.pem -key /tmp/s-time-key.pem -www
$ openssl s_time -connect 127.0.0.1:9443 -www / -time 2 -new \
    -no-CAfile -no-CApath -no-CAstore

Expected output includes Collecting connection statistics for 2 seconds, a connection count and a non-zero bytes read value. Repeat the last command with -reuse to exercise the second path. The temporary certificate is intentionally untrusted; the no-CA options keep this local performance check from loading the system trust store.

7. Diagnose the usual misleading results

• Connection refused: the host or port is wrong, or no service is listening. Check the endpoint with the service owner; changing -time will not fix it.
• Handshake failure: check the server's supported protocol and cipher policy. The command can select -tls1_2 or -tls1_3, but it cannot expose every protocol control available in s_client.
• Zero bytes read: you probably omitted -www, or the server did not return a payload. That is not a failed timing run if handshake-only measurement was intentional.
• Very different runs: check server load, network path, page size, duration and whether one run used -new while the other used -reuse.
• Unexpected certificate confidence: remember that -verify reports chain problems but, according to this command's documented behaviour, does not make the connection fail because of them.