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.

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 $100 credit for 60 days.

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 . 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.