OpenSSL test TLSv1.3 connection and ciphersuites with s_client
Published: 28-04-2019 | Author: Remy van Elst | Text only version of this article
Table of Contents
This guide shows you how to test a server's TLSv1.3 connection and use specific
ciphersuites with the command line
s_client client from the
With OpenSSL 1.1.1 you can use TLSv1.3. This guide covers the installation of
OpenSSL 1.1.1 on Ubuntu, testing the connection to a server and specific
ciphersuites. It also covers the big differences between TLSv1.3 and lower.
I often write about OpenSSL. You can see all my OpenSSL articles here
Installing OpenSSL 1.1.1 on Ubuntu 14.04, 16.04 or 18.04
The version of OpenSSL that ships with Ubuntu 16.04, 14.04 and 18.04 (and 18.10
but thats not an LTS) is not new enough to support TLSv1.3. You can either
compile OpenSSL yourself (download the source, extract,
which I would recommend you to do. It's easy and provides a local binary for
testing, not a systemwide upgrade. Ubuntu versions are built around specific
versions, so upgrading a core security component might not be the greatest idea.
As in, I don't know what will break when you upgrade OpenSSL system wide.
Or, you can use a PPA and upgrade OpenSSL systemwide. I recommend you only do this on a test system (one which you can afford to lose).
add-apt-repository ppa:ondrej/apache2 apt-get update apt-get install openssl
Again, I recommend you compile OpenSSL yourself.
You can check the OpenSSL version with this command:
OpenSSL 1.1.1 11 Sep 2018 (Library: OpenSSL 1.1.1b 26 Feb 2019)
Testing TLSv1.3 with s_client
s_client, one can test a server via the command line. This is usefull if
you want to quickly test if your server is configured correctly, get the
certificate or show the chain, or use in scripts. It's a lot faster than using
an online tool.
The command to test a server with TLSv1.3 specificly is:
echo | openssl s_client -tls1_3 -connect tls13.cloudflare.com:443
-showcerts option to see the entire certificate chain that is sent.
Here is a one liner to get the entire chain in a file
Example output for the cloudflare test server:
CONNECTED(00000003) depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA 2 verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = ssl412105.cloudflaressl.com verify return:1 --- Certificate chain 0 s:OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = ssl412105.cloudflaressl.com i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA 2 1 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA 2 i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority 2 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root --- Server certificate -----BEGIN CERTIFICATE----- MIIGkzCCBXugAwIBAgIRANJUlZPU4vFKFXext2DSsSswDQYJKoZIhvcNAQELBQAw [...] 1OrH66uB5EdBbYFjiAFoMkaeCNcxz7gPmzXBLg8bapzoLy0F7MHoUphWFRVgG0WX k5V11S6JgA== -----END CERTIFICATE----- subject=OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = ssl412105.cloudflaressl.com issuer=C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA 2 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 5138 bytes and written 324 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- DONE
In TLSv1.3 the meaning of ciphersuites changed. The new ciphersuites are defined
differently and do not specify the certificate type (e.g. RSA, DSA, ECDSA) or
the key exchange mechanism (e.g. DHE or ECHDE). The OpenSSL tooling has a new
option on the commandline for specifying TLSv1.3 ciphers (
openssl s_client -help [...] -cipher val Specify TLSv1.2 and below cipher list to be used -ciphersuites val Specify TLSv1.3 ciphersuites to be used
To test a server with one or more specific TLSv1.3 ciphersuites, use the
-ciphersuites commandline flag. First check which specific ciphersuites are
supported by your openssl version with this command:
openssl ciphers -v | grep TLSv1.3
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
So, to test if a server supports the
TLS_AES_256_GCM_SHA384 ciphersuite, use
the following command:
echo | openssl s_client -tls1_3 -ciphersuites 'TLS_AES_256_GCM_SHA384' -connect tls13.cloudflare.com:443
In the output under the connection information (below the certificates), you will see this if it succeeds:
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
To test multiple ciphers, provide them in client preferred order, seperated by a
echo | openssl s_client -tls1_3 -ciphersuites 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384' -connect tls13.cloudflare.com:443
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
The server will, if it supports the ciphersuite, use the clients preferred cipher.
If you enable TLSv1.3 in Apache (or any OpenSSL using program) and configure
specific ciphersuites, you must explicitly enable specific TLSv1.3 ciphersuites,
the first three are included in
DEFAULT. Otherwise a connection will fail.
Differences with TLSv1.2 and below
Citing the OpenSSL blog here verbatim:
TLSv1.3 is a major rewrite of the specification. There was some debate as to whether it should really be called TLSv2.0m but TLSv1.3 it is. There are major changes and some things work very differently. A brief, incomplete, summary of some things that you are likely to notice follows:
There are new ciphersuites that only work in TLSv1.3. The old ciphersuites cannot be used for TLSv1.3 connections.
The new ciphersuites are defined differently and do not specify the certificate type (e.g. RSA, DSA, ECDSA) or the key exchange mechanism (e.g. DHE or ECHDE). This has implications for ciphersuite configuration.
Clients provide a "key_share" in the ClientHello. This has consequences for "group" configuration. Sessions are not established until after the main handshake has been completed. There may be a gap between the end of the handshake and the establishment of a session (or, in theory, a session may not be established at all). This could have impacts on session resumption code.
Renegotiation is not possible in a TLSv1.3 connection
More of the handshake is now encrypted.
More types of messages can now have extensions (this has an impact on the custom extension APIs and Certificate Transparency)
DSA certificates are no longer allowed in TLSv1.3 connections