How do I test from TR7 which TLS versions and ciphers a server supports?

Short answer

sys-cmd sslscan in WEB-CLI connects to the target repeatedly and lists which TLS versions and ciphers it accepts, the cipher it prefers and the certificate it presents: sys-cmd sslscan --sni-name=<domain-name> <address>:<port>. If no port is written, 443 is assumed; if multiple certificates are presented on the same address, the correct name is sent with --sni-name=. When a Backend Service is tested, the route table of the Backend Service is first selected with sys-cmd route-table set. The result is compared with the settings of the TLS Security Profile selected in the SSL Security field on the vService and in the Backend SSL Security Profile field on the Backend Service.

Problem: The Externally Visible Result of the TLS Settings Is Unknown

After the TLS profile of a vService is changed, the aim is to verify that the old versions are really turned off, or which versions and ciphers the server accepts when the Backend Service is connected to over HTTPS. Since TR7 connects to the Backend Service from its own network, the test must be run from the route table of TR7 to see the TLS settings the server presents to TR7.

Solution

Scanning with sys-cmd sslscan

• How it workssys-cmd sslscan tries a separate handshake for each TLS version and cipher; in the result, it writes the accepted versions, the ciphers, the preferred cipher and the certificate details. It closes on its own when the scan finishes.
• Where it is openedWEB-CLI
• Requirement A user whose User Type is Admin; access to the target from the selected route table.
• vService type HTTP and L7 TCP vServices that terminate TLS; Backend Services that listen on HTTPS

Step-by-Step Configuration

1

Adım 1 Select the route table

If the Backend Service is to be tested, the Route Table value of the Backend Service is selected; if the vService is to be tested, the route table through which its frontend IP is reached is selected; for the device itself, Host is written in the v-device field, and the route table name is taken from the Tab list:

sys-cmd route-table set v-device Host route-table <route-table>

2

Adım 2 Scan the TLS settings of the vService

In the example, the vService with the frontend IP 203.0.113.10 is scanned by sending the name www.example.com:

sys-cmd sslscan --sni-name=www.example.com 203.0.113.10:443

3

Adım 3 Scan the TLS settings of the Backend Service

In the example, port 8443 of the server with the address 192.0.2.21 is scanned. If SNI is defined in the Backend Service, the same name is sent with --sni-name=:

sys-cmd sslscan --sni-name=app.example.com 192.0.2.21:8443

To try only a specific version, --tls12 or --tls13 is added.

4

Adım 4 Inspect the certificate (optional)

For all the details of the presented certificate, the scan is run with the cipher list skipped:

sys-cmd sslscan --sni-name=www.example.com --show-certificate --no-ciphersuites 203.0.113.10:443

5

Adım 5 Save the result (optional)

The result is written to a file with the colored output turned off; the download link is obtained with sys-cmd file show vip-tls.txt:

sys-cmd sslscan --no-colour --sni-name=www.example.com 203.0.113.10:443 | to-file vip-tls.txt

6

Adım 6 Compare with the profile

The profile selected in the SSL Security field for the vService, or in the Backend SSL Security Profile field for the Backend Service, is opened. The lowest and highest versions accepted in the scan are compared with the Min. SSL Version and Max. SSL Version values of the profile, and the cipher list with the Cipher Algorithms selection. For the Backend Service, there must be at least one common version and one common cipher between the versions and ciphers TR7 allows and those seen in the scan; if there is no common value, TR7 cannot establish the TLS handshake with the server. If no profile is selected in the Backend Service, the selection in the Ciphers field applies.

Verification

1Versions and ciphersTR7 side

The protocol and cipher sections of the scan are checked.

Command: sys-cmd sslscan --sni-name=www.example.com 203.0.113.10:443

ExpectedOnly the versions allowed in the profile are enabled; no cipher outside the profile in the list

2CertificateTR7 side

The subject and validity information in the --show-certificate output is checked.

ExpectedThe certificate of the sent name, within its validity period

Common Mistakes

• Scanning without --sni-name=. If multiple domain names are served on the same address, a scan that sends no server name shows the default certificate; the result may belong to the settings of another site.
• Scanning the Backend Service from the default route table. A server in an isolated route table cannot be reached from the default context; the scan is run with the route table of the Backend Service selected.
• Scanning repeatedly during peak hours. sslscan opens a separate connection for each version and cipher; on a live vService, a large number of connections are created in a short time.
• Taking the scan result as the result all clients will see. The result is the state seen from the selected route table of TR7; if there is another TLS-terminating device in front of TR7, the settings the clients see are tested separately from the client side.
• Looking for the flow of a connection with sslscan. sslscan lists the supported settings; for the handshake steps of a single connection, sys-cmd ssldump is used.

How it is done in the documentation

• sys-cmd sslscan · Frequently Used Parameters
• sys-cmd sslscan · Things to Know
• TLS Security Profiles · Min. SSL Version
• TLS Security Profiles · Cipher Algorithms
• Backend Services · Backend SSL Security Profile

Related questions

• How do I disable TLS 1.0/1.1; is TLS 1.3 supported?
• How do I disable weak ciphers?
• What is a TLS Security Profile, and what does it configure?
• I need to send SNI when connecting to the backend; how do I set it up?