This is a text-only version of the following page on https://raymii.org:
---
Title : OpenSSL test TLSv1.3 connection and ciphersuites with s_client
Author : Remy van Elst
Date : 28-04-2019
URL : https://raymii.org/s/tutorials/OpenSSL_test_TLSv1.3_connection_with_s_client.html
Format : Markdown/HTML
---
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.
<p class="ad"> <b>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:</b><br><br> <a href="https://leafnode.nl">I'm developing an open source monitoring app called Leaf Node Monitoring, for windows, linux & android. Go check it out!</a><br><br> <a href="https://github.com/sponsors/RaymiiOrg/">Consider sponsoring me on Github. It means the world to me if you show your appreciation and you'll help pay the server costs.</a><br><br> <a href="https://www.digitalocean.com/?refcode=7435ae6b8212">You can also sponsor me by getting a Digital Ocean VPS. With this referral link you'll get $100 credit for 60 days. </a><br><br> </p>
I often write about OpenSSL. [You can see all my OpenSSL articles here][2]
### 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][3]
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][4] by the [OpenSSL team][5].
### Differences with TLSv1.2 and below
Citing the [OpenSSL blog here verbatim][6]:
* 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
[1]: https://www.digitalocean.com/?refcode=7435ae6b8212
[2]: https://raymii.org/s/tags/openssl.html
[3]: https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_against_a_CRL.html#Getting_the_certificate_chain
[4]: https://github.com/openssl/openssl/issues/5065
[5]: https://github.com/openssl/openssl/issues/5057
[6]: http://web.archive.org/web/20190428143322/https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
---
License:
All the text on this website is free as in freedom unless stated otherwise.
This means you can use it in any way you want, you can copy it, change it
the way you like and republish it, as long as you release the (modified)
content under the same license to give others the same freedoms you've got
and place my name and a link to this site with the article as source.
This site uses Google Analytics for statistics and Google Adwords for
advertisements. You are tracked and Google knows everything about you.
Use an adblocker like ublock-origin if you don't want it.
All the code on this website is licensed under the GNU GPL v3 license
unless already licensed under a license which does not allows this form
of licensing or if another license is stated on that page / in that software:
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
Just to be clear, the information on this website is for meant for educational
purposes and you use it at your own risk. I do not take responsibility if you
screw something up. Use common sense, do not 'rm -rf /' as root for example.
If you have any questions then do not hesitate to contact me.
See https://raymii.org/s/static/About.html for details.