When using a Cisco FTD firewall for SSL/TLS Remote Access VPN, the appliance is enabled by default with TLS versions 1.0, 1.1 and 1.2. TLS versions 1.0 and 1.1 are considered insecure and depreciated in most browsers/operating systems. Most modern operating systems such as Windows 10 come with TLS version 1.2 support as default, so versions 1.0 and 1.1 can safely be disabled. Be careful with older version of windows such as unpatched Windows 7, TLSv1.0 is enabled as default and TLSv1.1 and TLSv1.2 have to be manually enabled.

This post describes the steps to disable the older TLS protocols and ensure the strongest ciphers are enabled. In this scenario FMC and FTD are both running version 6.5, with the client computers running AnyConnect 4.8 or 4.9.

FTD Configuration

Run an NMAP scan on the outside interface IP address of the FTD configured for SSL-VPN Remote Access VPN, use the syntax nmap –script -ssl-enum-ciphers -p 443 <ip address>. From the screenshot below we can determine TLSv1.0, TLSv1.1 and TLSv1.2 protocols are enabled. There is also a warning that Key Exchange (DH) is weak.

Login to the CLI of the FTD, run the command show ssl. From the screenshot below we can confirm TLSv1 is allowed and the SSL DH Group is Group2 with a warning that this is DEPRECIATED.

Run the command show running-config all ssl. From the screenshot below, we can confirm the SSL ciphers in use are set to medium.

The SSL/TLS protocols and ciphers algorithms on an FTD, are controlled using the Platform Settings policy on an FTD managed by a Firepower Management Centre (FMC). Navigate to Devices > Platform Settings and modify the existing policy (if configured) or create new. Click the SSL tab

As is evident by the screenshot below, the default SSL settings specify the minimum SSL version as TLSv1 – which confirms the output from the show ssl command previously run.

• From the Minimum SSL version as Server: drop-down list select – TLSV1.2
• From the Diffie-Hellman Group: drop-down list select – Group 14
• Deploy the changes to the FTD

NOTE – From FTD/FMC version 6.6 and greater DTLS version 1.2 is supported, on the FTD version 6.5 used in this scenario only DTLSv1.0 is supported. DTLSv1.2 is recommended for best performance.

• From the CLI of the FTD confirm the settings have been applied, run the command show ssl.

From the screenshot below, we can confirm that the FTD will negotiate TLSv1.2 or greater connections and that the SSL DH Group is now group14, and no warning that the group is depreciated.

Re-run the NMAP scan. From the output of the screenshot below, we can confirm that only TLSv1.2 is enabled and no warning that the Key Exchange is of lower strength.

If we wished to limit the number of available of TLSv1.2 ciphersuites available, we can do this by modifying the Platform Settings Policy

• On the FMC navigate to Devices > Platform Settings and modify the existing policy
• Click the SSL tab
• Click the Add button

It was previously determined in the output of show running-config all ssl that the default TLSv1.2 security level was set to medium. We can either select “High” or “Custom”.

• To create a custom list, select Custom security level
• From the Available Algorithms column, select the desired algorithms and click Add.
• Click Ok, once complete
• Deploy the policy to the FTD

Re-run the NMAP scan to confirm the enabled ciphers reflects the configured algorithms defined in the policy.

Connect an AnyConnect client to the VPN.

From the CLI of the FTD run the command, show vpn-sessiondb detail anyconnect and confirm the ciphersuite used by the connected session.

Packet Capture TLS communication

In some circumstances it might be useful to perform a packet capture of the TLS traffic on the FTD, the following steps details how to take a packet capture and confirm the output.

• Login to the CLI of the FTD, run the command system support diagnostic-cli
• Type enable press enter when prompted for the password (there is no password)
• Confirm a packet, e.g.

capture CAPO buffer 16000 interface OUTSIDE match tcp any host <outside interface ip> eq 443

• Run the command show capture CAPO and confirm packets have been captured.
• Run the following command to copy the pcap file to a remote SCP server

copy /pcap capture:CAPO scp://<ip address>

• Open the CAPO pcap file in wireshark

From the screenshot below, we can confirm a successful TCP 3-way handshake. The 4^th packet is from the AnyConnect indication to the FTD the TLS cipher suites it supports (21 in total).

The 6^th packet is the “Server Hello” packet, with the FTD selecting the Cipher Suite to use – TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

From the CLI of the FTD, run the command show vpn-sessiondb detail anyconnect and confirm the ciphersuite. As we can determine from the screenshot below, the ECDHE-RSA-AES256-GCM-SHA384 ciphersuite is in use for the authenticated session, as indicated in the packet capture above.

If the FTD and client computer did not mutually support the same ciphersuite, the AnyConnect client would fail to connect with an error similar to the image below.

Running a packet capture on the FTD, from the output below confirm the ciphersuite supported by the client in the “Client Hello” packet. In the image below we can determine the client supports 3 suites.

In the 6^th packet instead of seeing a “Server Hello” indicating the negotiated mutual ciphersuite supported by both the FTD and the client, we see a “Fatal, Description: Handshake Failure” message.

To resolve this issue, the ciphersuites listed in the “Client Hello” packet would need to be added to the supported ciphersuite list under the Platform Settings Policy of the FTD. Or preferably the client should be investigated as to why it does not support stronger ciphers.