Skip to Content

SSL vs TLS and how to check TLS version in Linux

Both SSL and TLS protocols aim to protect sensitive information used during transactions such as payment processing that requires authentication to prove the identity of our server to the users.

TLS 1.3 is the latest version of the TLS protocol.  It is a descendent of SSL and is regarded to be more powerful and effective.

OpenSSL command is the easiest way to check TLS version. The following commands can be used to find TLS version:

  • openssl s_client -connect host.com:443 -tls1
  • openssl s_client -connect host.com:443 -tls1_1
  • openssl s_client -connect host.com:443 -tls1_2
  • openssl s_client -connect host.com:443 -tls1_3
  • nmap –script ssl-enum-ciphers -p 443 host.com

 

Understanding SSL

SSL stands for “Secure Socket Layer.”

  • Netscape developed the first version of SSL in 1995.
  • SSL is a cryptographic protocol that uses explicit connections to establish secure communication between web server and client.
  • Three versions of SSL have been released: SSL 1.0, 2.0, and 3.0.
  • All versions of SSL have been found vulnerable, and they all have been deprecated.

 

Understanding TLS

TLS stands for “Transport Layer Security.”

  • The first version of TLS was developed by the Internet Engineering Taskforce (IETF) in 1999.
  • Four versions of TLS have been released: TLS 1.0, 1.1, 1.2, and 1.3.
  • TLS is also a cryptographic protocol that provides secure communication between web server and client via implicit connections. It’s the successor of SSL protocol.
  • TLS 1.0 and 1.1 have been “broken” and are deprecated as of March 2020. TLS 1.2 is the most widely deployed protocol version.

 

Which is more secure for SSL and TLS?

TLS provides a more robust message authentication system, key material generation along other encryption algorithms when compared to SSL. Thus, TLS provides support with remote passwords, elliptical curve keys and pre-shared keys which are not supported by SSL. TLS still provides backward compatibility for older devices.

The TLS protocol works on two layers where the TLS record protocol provides security to connections. The TLS handshake protocol brings together the client and the server for security key negotiation. Both client and the server authenticate each other before any data transmission.

Understanding SSL Certificates and TLS Certificates

That’s because both “SSL certificate” and “TLS certificate” essentially mean the same thing: They’re both X.509 digital certificates that help to authenticate the server and facilitate the handshake process to create a secure connection.

Some people call them “SSL certificates,” while others refer to them as “TLS certificates.”

The name doesn’t matter much because a certificate isn’t the same thing as the protocol. Whatever we call them, what matters is the protocol that it operates on. And these protocols are determined by our server configuration, not by the digital certificates.

Latest TLS version

TLS 1.3 improves upon its predecessors (TLS 1.0, TLS 1.1, and TLS 1.2) by providing better security, reducing latency, and enhancing overall performance.

TLS 1.3 introduces significant changes to the handshake process, ciphersuites, and encryption algorithms, resulting in a more streamlined and secure communication between clients and servers. Some of the key features of TLS 1.3 include:

  1. Improved Security: TLS 1.3 eliminates older, less secure cryptographic algorithms and cipher suites, providing stronger encryption and better protection against attacks.
  2. Faster Handshake: TLS 1.3 reduces the number of round trips required during the handshake process, resulting in faster connection establishment.

 

Check TLS version on SSLlabs

SSL Labs is a tool  for SSL/TLS testing purpose. It allows you to analyze the SSL/TLS configuration of a given website or IP address.

When you access this URL, the SSL Labs tool performs a series of tests and assessments on the SSL/TLS configuration of the specified domain (google.com) or IP address (142.251.40.46). It checks various aspects of the configuration, including the supported TLS versions, cipher suites, certificate validity, and other security-related settings.

The tool generates a detailed report on the SSL/TLS configuration and assigns a grade (from A+ to F) based on the overall security and compliance level.

Using this SSL Labs tool, you can gain insights into the SSL/TLS security of a website or IP address, helping you assess its security posture and identify potential vulnerabilities or misconfigurations.

Check TLS version in Linux

OpenSSL is a popular open-source library that provides support for the SSL/TLS protocols, used for securing communications over a network.

When we refer to OpenSSL TLS version, we are talking about the TLS versions supported by the OpenSSL library itself.

OpenSSL supports various TLS versions, including TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3.

The specific TLS versions supported by OpenSSL may vary depending on the version of the OpenSSL library installed on your system.

The command below is used to list the available SSL/TLS ciphers supported by the OpenSSL library.  

openssl ciphers -v | awk '{print $2}' | sort | uniq

Let’s break down the command step by step:

  1. openssl ciphers -v: This part of the command calls the OpenSSL tool and uses the ciphers option to list all the available ciphers along with their details. The v flag displays additional information about the ciphers, including their version and key exchange algorithm.
  2. awk ‘{print $2}’: The output from the previous command contains multiple columns, and this awk command is used to extract only the second column, which contains the cipher names.
  3. sort: The sort command is used to sort the list of cipher names alphabetically. This will arrange the cipher names in ascending order.
  4. uniq: The uniq command is used to remove duplicate entries from the sorted list. Since some ciphers may have multiple versions or variations, using uniq ensures that each cipher name appears only once in the final output.

 

Here is the output on my system.

$ openssl ciphers -v | awk '{print $2}' | sort | uniq
SSLv3
TLSv1
TLSv1.2
TLSv1.3

Check the TLS version for a remote server in Linux

In the context of applications, such as web browsers, web servers, or other network services, the TLS version refers to the specific TLS protocol version negotiated during the secure connection establishment.

When a client (e.g., web browser) connects to a server (e.g., web server) over HTTPS or other TLS-encrypted protocols, they negotiate the highest TLS version that both the client and server support.

This is called the TLS handshake. The client sends a ClientHello message indicating the TLS versions it supports, and the server responds with a ServerHello message, indicating the TLS version that will be used for the connection.

The selected TLS version can depend on various factors, including the TLS version preferences of the client and server, as well as any limitations or security configurations set by the server administrator.

For example, if a client supports TLS 1.2 and TLS 1.3, and the server also supports both versions, they may agree to use TLS 1.3 for the connection if it is the highest common version.

Some vendors already have terminated the support for earlier TLS versions (TLS 1.0 and TLS 1.1) and have completely migrated to TLS version 1.2 even 1.3.

Here’s how you can check TLS version for a remote server in Linux using openssl command.

  1. Open a terminal on your Linux system.
  2. Type the following command to check the TLS version supported by a specific website:
    openssl s_client -connect example.com:443 -tls1_2
  3. Replace example.com with the domain or website you want to check. The option -tls1_2 specifies that you want to check the TLS 1.2 version specifically. You can replace it with -tls1_3 or other versions to check different TLS versions.
  4. Look for Protocol and Cipher under ssl-session section.

 

In the openssl s_client command, the Session-ID refers to a unique identifier assigned to an SSL/TLS session.

When a client establishes a secure connection with a server, the server generates a Session-ID during the SSL/TLS handshake process. This identifier is used to keep track of the session and can be helpful in troubleshooting and optimizing SSL/TLS connections.

$ openssl s_client -connect example.com:443
...
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Session-ID: 9D4AB728AEF03A1FCB48A84E633

But in TLS1.3, the session_id is not there.

We can look for Protocol and Cipher in the command output.

SSL-Session:
Protocol : TLSv1.3
Cipher : AEAD-AES256-GCM-SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1690622494
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 0DA695FD790F2D625E9318526145
Session-ID-ctx:
Master-Key: 99BC836BE3CB60F47A728E6F
TLS session ticket lifetime hint: 300 (seconds)

SSL-Session:
Protocol : TLSv1.1
Cipher : ECDHE-ECDSA-AES128-SHA
Session-ID: 5D871ED53A810BB2D3AF2A921
Session-ID-ctx:
Master-Key: B53E3BD441E085CD6EFBEE
TLS session ticket lifetime hint: 100800 (seconds)

SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-ECDSA-AES128-SHA
Session-ID: 796903378BF24CAF1B4CC4
Session-ID-ctx:
Master-Key: 8251999BDF60554E43
TLS session ticket lifetime hint: 100800 (seconds)

We can use the following command to check if which TLS version google.com supports. 

#openssl s_client -connect www.google.com:443 -tls1
#openssl s_client -connect www.google.com:443 -tls1_1
#openssl s_client -connect www.google.com:443 -tls1_2
#openssl s_client -connect www.google.com:443 -tls1_3

 

  • -tls1 for TLSv1
  • -tls1_1 for TLSv1.1
  • -tls1_2 for TLSv1.2

 

This article covers more examples about how to use openssl s_client comannd.

Here is one useful command to get all the supported tls version from remote server.

for proto in 1 1_1 1_2 1_3; do echo tls${proto}; openssl s_client -connect google.com:443 "-tls${proto}" 2>/dev/null < <(sleep 1; echo q) | egrep 'Protocol|Cipher' |grep -v is|  uniq; done

Here is the output on my system.

tls1
Protocol : TLSv1
Cipher : ECDHE-RSA-AES128-SHA
tls1_1
Protocol : TLSv1.1
Cipher : ECDHE-RSA-AES128-SHA
tls1_2
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305
tls1_3
Protocol : TLSv1.3
Cipher : AEAD-AES256-GCM-SHA384

Alternatively, you can omit the specific TLS version option to let openssl negotiate the supported version automatically:

openssl s_client -connect example.com:443

This command will establish an SSL/TLS connection to the specified domain on the default HTTPS port (443) and display information about the negotiated TLS version.

Please note that the openssl command should be installed on your Linux system for these commands to work. If it’s not available, you may need to install it using your package manager, such as apt or yum.

We can also use nmap command to check the TLS version in Linux.

nmap --script ssl-enum-ciphers -p 443 www.google.com

When you execute this command, Nmap will initiate a scan against the target domain on port 443.

The ssl-enum-ciphers script will then perform a series of tests to enumerate the supported SSL/TLS ciphers on the server. It will gather information about the cipher suites, their strength, encryption algorithms, and other relevant details.

The script will generate a report that lists the identified SSL/TLS ciphers and their associated properties.

This information can be helpful in assessing the security level and cipher suite configuration of the target server.

# nmap --script ssl-enum-ciphers -p 443 www.google.com
Starting Nmap 7.70 ( https://nmap.org ) at 2023-05-27 08:05 GMT
Nmap scan report for www.google.com (142.251.46.228)
Host is up (0.00062s latency).
Other addresses for www.google.com (not scanned): 2607:f8b0:4005:810::2004
rDNS record for 142.251.46.228: sfo03s27-in-f4.1e100.net

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 1.28 seconds

 

4 Ways to Check SSL certificate

 

Related:

Mg Nihuy

Thursday 23rd of November 2023

I finally fixed my issue with the help of this article. Thank you.

David Cao

Thursday 23rd of November 2023

Glad to see it. Thanks for the comment.

Daniel Li

Wednesday 20th of September 2023

Cool. Thanks a lot for this article. It is very helpful.