Raymii.org
Quis custodiet ipsos custodes?Home | About | All pages | Cluster Status | RSS Feed
OpenSSL test TLSv1.3 connection and ciphersuites with s_client
Published: 28-04-2019 | Author: Remy van Elst | Text only version of this article
❗ This post is over five years old. It may no longer be up to date. Opinions may have changed.
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 OpenSSL project.
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.
Recently I removed all Google Ads from this site due to their invasive tracking, as well as Google Analytics. Please, if you found this content useful, consider a small donation using any of the options below:
I'm developing an open source monitoring app called Leaf Node Monitoring, for windows, linux & android. Go check it out!
Consider sponsoring me on Github. It means the world to me if you show your appreciation and you'll help pay the server costs.
You can also sponsor me by getting a Digital Ocean VPS. With this referral link you'll get $200 credit for 60 days. Spend $25 after your credit expires and I'll get $25!
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, ./configure, make),
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 version
My output:
OpenSSL 1.1.1 11 Sep 2018 (Library: OpenSSL 1.1.1b 26 Feb 2019)
Testing TLSv1.3 with s_client
Using 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
Append the -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
Specific ciphersuites
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 (ciphersuites):
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
Example output:
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
Or:
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
To test multiple ciphers, provide them in client preferred order, seperated by a
colon (:):
echo | openssl s_client -tls1_3 -ciphersuites 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384' -connect tls13.cloudflare.com:443
Output:
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.
This was a deliberate decision by the OpenSSL team.
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