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 specificciphersuites with the command line
s_client client from the
OpenSSL project.With OpenSSL 1.1.1 you can use TLSv1.3. This guide covers the installation ofOpenSSL 1.1.1 on Ubuntu, testing the connection to a server and specificciphersuites. 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.10but thats not an LTS) is not new enough to support TLSv1.3. You can eithercompile OpenSSL yourself (download the source, extract,
make),which I would recommend you to do. It's easy and provides a local binary fortesting, not a systemwide upgrade. Ubuntu versions are built around specificversions, 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 dothis on a test system (one which you can afford to lose).
add-apt-repository ppa:ondrej/apache2apt-get updateapt-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 ifyou want to quickly test if your server is configured correctly, get thecertificate or show the chain, or use in scripts. It's a lot faster than usingan 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 Authorityverify return:1depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA 2verify return:1depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = ssl412105.cloudflaressl.comverify 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[...]1OrH66uB5EdBbYFjiAFoMkaeCNcxz7gPmzXBLg8bapzoLy0F7MHoUphWFRVgG0WXk5V11S6JgA==-----END CERTIFICATE-----subject=OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = ssl412105.cloudflaressl.comissuer=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 sentPeer signing digest: SHA256Peer signature type: RSA-PSSServer Temp Key: X25519, 253 bits---SSL handshake has read 5138 bytes and written 324 bytesVerification: OK---New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384Server public key is 2048 bitSecure Renegotiation IS NOT supportedCompression: NONEExpansion: NONENo ALPN negotiatedEarly data was not sentVerify return code: 0 (ok)---DONE
In TLSv1.3 the meaning of ciphersuites changed. The new ciphersuites are defineddifferently and do not specify the certificate type (e.g. RSA, DSA, ECDSA) orthe key exchange mechanism (e.g. DHE or ECHDE). The OpenSSL tooling has a newoption 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 aresupported 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=AEADTLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEADTLS_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, usethe 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), youwill 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 acolon (
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 preferredcipher.
If you enable TLSv1.3 in Apache (or any OpenSSL using program) and configurespecific 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