Information about the TLS Proxy for Encrypted Voice Inspection
End-to-end encryption often leaves network security appliances “blind” to media and signaling traffic, which can compromise access control and threat prevention security functions. This lack of visibility can result in a lack of interoperability between the firewall functions and the encrypted voice, leaving businesses unable to satisfy both of their key security requirements.
The ASA is able to intercept and decrypt encrypted signaling from Cisco encrypted endpoints to the Cisco Unified Communications Manager (Cisco UCM), and apply the required threat protection and access control. It can also ensure confidentiality by re-encrypting the traffic onto the Cisco UCM servers.
Typically, the ASA TLS Proxy functionality is deployed in campus unified communications network. This solution is ideal for deployments that utilize end to end encryption and firewalls to protect Unified Communications Manager servers.
Decryption and Inspection of Unified Communications Encrypted Signaling
With encrypted voice inspection, the security appliance decrypts, inspects and modifies (as needed, for example, performing NAT fixup), and re-encrypts voice signaling traffic while all of the existing VoIP inspection functions for Skinny and SIP protocols are preserved. Once voice signaling is decrypted, the plaintext signaling message is passed to the existing inspection engines.
The security appliance acts as a TLS proxy between the Cisco IP Phone and Cisco UCM. The proxy is transparent for the voice calls between the phone and theCisco UCM. Cisco IP Phones download a Certificate Trust List from the Cisco UCM before registration which contains identities (certificates) of the devices that the phone should trust, such as TFTP servers and Cisco UCM servers. To support server proxy, the CTL file must contain the certificate that the security appliance creates for the Cisco UCMs. To proxy calls on behalf of the Cisco IP Phone, the security appliance presents a certificate that the Cisco UCM can verify, which is a Local Dynamic Certificate for the phone, issued by the certificate authority on the security appliance.
TLS proxy is supported by the Cisco Unified CallManager Release 5.1 and later. You should be familiar with the security features of the Cisco UCM. For background and detailed description of Cisco UCM security, see the Cisco Unified CallManager document:
TLS proxy applies to the encryption layer and must be configured with an application layer protocol inspection. You should be familiar with the inspection features on the ASA, especially Skinny and SIP inspection.
Supported Cisco UCM and IP Phones for the TLS Proxy
Cisco Unified Communications Manager
The following releases of the Cisco Unified Communications Manager are supported with the TLS proxy:
Cisco Unified CallManager Version 4.
Cisco Unified CallManager Version 5.0
Cisco Unified CallManager Version 5.1
Cisco Unified Communications Manager 6.1
Cisco Unified Communications Manager 7.0
Cisco Unified Communications Manager 8.0
Cisco Unified IP Phones
The following IP phones in the Cisco Unified IP Phones 7900 Series are supported with the TLS proxy:
Cisco Unified IP Phone 7985
Cisco Unified IP Phone 7975
Cisco Unified IP Phone 7971
Cisco Unified IP Phone 7970
Cisco Unified IP Phone 7965
Cisco Unified IP Phone 7962
Cisco Unified IP Phone 7961
Cisco Unified IP Phone 7961G-GE
Cisco Unified IP Phone 7960
Cisco Unified IP Phone 7945
Cisco Unified IP Phone 7942
Cisco Unified IP Phone 7941
Cisco Unified IP Phone 7941G-GE
Cisco Unified IP Phone 7940
Cisco Unified Wireless IP Phone 7921
Cisco Unified Wireless IP Phone 7925
Cisco IP Communicator (CIPC) for softphones
CTL Client Overview
The CTL Client application supplied by Cisco Unified CallManager Release 5.1 and later supports a TLS proxy server (firewall) in the CTL file. Figure 17-1 through Figure 17-4 illustrate the TLS proxy features supported in the CTL Client.
Figure 17-1 CTL Client TLS Proxy Features — Add Firewall
Figure 17-1 shows support for adding a CTL entry consisting of the security appliance as the TLS proxy.
Figure 17-2 CTL Client TLS Proxy Features — ASA IP Address or Domain Name
Figure 17-2 shows support for entering the security appliance IP address or domain name in the CTL Client.
Figure 17-3 CTL Client TLS Proxy Features — CTL Entry for ASA
Figure 17-3 shows that the CTL entry for the security appliance as the TLS proxy has been added. The CTL entry is added after the CTL Client connects to the CTL Provider service on the security appliance and retrieves the proxy certificate.
Figure 17-4 CTL Client TLS Proxy Features — CTL File Installed on the ASA
The security appliance does not store the raw CTL file in the flash, rather, it parses the CTL file and installs appropriate trustpoints. Figure 17-4 indicates the installation was successful.
Licensing for the TLS Proxy
The TLS proxy for encrypted voice inspection feature supported by the ASA require a Unified Communications Proxy license.
The following table shows the Unified Communications Proxy license details by platform:
Note This feature is not available on No Payload Encryption models.
1.The following applications use TLS proxy sessions for their connections. Each TLS proxy session used by these applications (and only these applications) is counted against the UC license limit: - Phone Proxy - Presence Federation Proxy - Encrypted Voice Inspection
Other applications that use TLS proxy sessions do not count towards the UC limit, for example, Mobility Advantage Proxy (which does not require a license) and IME (which requires a separate IME license).
Some UC applications might use multiple sessions for a connection. For example, if you configure a phone with a primary and backup Cisco Unified Communications Manager, there are 2 TLS proxy connections, so 2 UC Proxy sessions are used.
You independently set the TLS proxy limit using the tls-proxy maximum-sessions command. To view the limits of your model, enter the tls-proxy maximum-sessions ? command. When you apply a UC license that is higher than the default TLS proxy limit, the ASA automatically sets the TLS proxy limit to match the UC limit. The TLS proxy limit takes precedence over the UC license limit; if you set the TLS proxy limit to be less than the UC license, then you cannot use all of the sessions in your UC license.
Note: For license part numbers ending in “K8” (for example, licenses under 250 users), TLS proxy sessions are limited to 1000. For license part numbers ending in “K9” (for example, licenses 250 users or larger), the TLS proxy limit depends on the configuration, up to the model limit. K8 and K9 refer to whether the license is restricted for export: K8 is unrestricted, and K9 is restricted.
Note: If you clear the configuration (using the clear configure all command, for example), then the TLS proxy limit is set to the default for your model; if this default is lower than the UC license limit, then you see an error message to use the tls-proxy maximum-sessions command to raise the limit again . If you use failover and enter the write standby command on the primary unit to force a configuration synchronization, the clear configure all command is generated on the secondary unit automatically, so you may see the warning message on the secondary unit. Because the configuration synchronization restores the TLS proxy limit set on the primary unit, you can ignore the warning.
You might also use SRTP encryption sessions for your connections: - For K8 licenses, SRTP sessions are limited to 250. - For K9 licenses, there is not limit.
Note: Only calls that require encryption/decryption for media are counted towards the SRTP limit; if passthrough is set for the call, even if both legs are SRTP, they do not count towards the limit.
2.With the 10,000-session UC license, the total combined sessions can be 10,000, but the maximum number of Phone Proxy sessions is 5000.
Table 17-1 shows the default and maximum TLS session details by platform.
Table 17-1 Default and Maximum TLS Sessions on the Security Appliance
Prerequisites for the TLS Proxy for Encrypted Voice Inspection
Before configuring TLS proxy, the following prerequisites are required:
You must set clock on the security appliance before configuring TLS proxy. To set the clock manually and display clock, use the clock set and show clock commands. We recommend that the security appliance use the same NTP server as the Cisco Unified CallManager cluster. TLS handshake may fail due to certificate validation failure if clock is out of sync between the security appliance and the Cisco Unified CallManager server.
3DES-AES license is needed to interoperate with the Cisco Unified CallManager. AES is the default cipher used by the Cisco Unified CallManager and Cisco IP Phone.
Import the following certificates which are stored on the Cisco UCM. These certificates are required by the ASA for the phone proxy.
– CAPF certificate (Optional)
If LSC provisioning is required or you have LSC enabled IP phones, you must import the CAPF certificate from the Cisco UCM. If the Cisco UCM has more than one CAPF certificate, you must import all of them to the ASA.
Task flow for Configuring the TLS Proxy for Encrypted Voice Inspection
To configure the security appliance for TLS proxy, perform the following steps:
Step 1 (Optional) Set the maximum number of TLS proxy sessions to be supported by the security appliance using the following command, for example:
ciscoasa(config)# tls-proxy maximum-sessions 1200
Note The tls-proxy maximum-sessions command controls the memory size reserved for cryptographic applications such as TLS proxy. Crypto memory is reserved at the time of system boot. You may need to reboot the security appliance for the configuration to take effect if the configured maximum sessions number is greater than the currently reserved.
Step 8 Run the CTL Client application to add the server proxy certificate (ccm_proxy) to the CTL file and install the CTL file on the security appliance. See the Cisco Unified CallManager document for information on how to configure and use CTL Client:
Note You will need the CTL Client that is released with Cisco Unified CallManager Release 5.1 to interoperate with the security appliance. See the “CTL Client Overview” section for more information regarding TLS proxy support.
Creating Trustpoints and Generating Certificates
The Cisco UCM proxy certificate could be self-signed or issued by a third-party CA. The certificate is exported to the CTL client.
Includes the indicated subject DN in the certificate during enrollment
Cisco IP Phones require certain fields from the X.509v3 certificate to be present to validate the certificate via consulting the CTL file. Consequently, the subject-name entry must be configured for a proxy certificate trustpoint. The subject name must be composed of the ordered concatenation of the CN, OU and O fields. The CN field is mandatory; the others are optional.
Note Each of the concatenated fields (when present) are separated by a semicolon, yielding one of the following forms: CN=xxx;OU=yyy;O=zzz CN=xxx;OU=yyy CN=xxx;O=zzz CN=xxx
Specifies the key pair whose public key is to be certified.
Exits from the CA Trustpoint configuration mode.
crypto ca enroll
ciscoasa(config)# crypto ca enroll ccm_proxy
Starts the enrollment process with the CA and specifies the name of the trustpoint to enroll with.
What to Do Next
Once you have created the trustpoints and generated the certificates, create the internal CA to sign the LDC for Cisco IP Phones. See Creating an Internal CA.
Creating an Internal CA
Create an internal local CA to sign the LDC for Cisco IP Phones.
This local CA is created as a regular self-signed trustpoint with proxy-ldc-issuer enabled. You can use the embedded local CA LOCAL-CA-SERVER on the ASA to issue the LDC.
ciscoasa(config)# crypto ca trustpoint
ciscoasa(config)# ! for the internal local LDC issuer
ciscoasa(config)# crypto ca trustpoint ldc_server
Enters the trustpoint configuration mode for the specified trustpoint so that you can create the trustpoint for the LDC issurer.
ciscoasa(config-ca-trustpoint)# enrollment self
Generates a self-signed certificate.
Issues TLS proxy local dynamic certificates. The
command grants a crypto trustpoint the role as local CA to issue the LDC and can be accessed from crypto ca trustpoint configuration mode.
command defines the local CA role for the trustpoint to issue dynamic certificates for TLS proxy. This command can only be configured under a trustpoint with "enrollment self."
Create a CTL Provider instance in preparation for a connection from the CTL Client.
The default port number listened by the CTL Provider is TCP 2444, which is the default CTL port on the Cisco UCM. Use the service port command to change the port number if a different port is used by the Cisco UCM cluster.
ciscoasa(config)# ctl-provider my_ctl
Enters the CTL provider configuration mode so that you can create the Certificate Trust List provider instance.
Specifies the certificate to be exported to the client. The certificate will be added to the Certificate Trust List file composed by the CTL client.
The trustpoint name in the export command is the proxy certificate for the Cisco UCM server.
ciscoasa(config-ctl-provider)# ctl install
Enables the CTL provider to parse the CTL file from the CTL client and install trustpoints for entries from the CTL file. Ttrustpoints installed by this command have names prefixed with "_internal_CTL_<ctl_name>."
Create the TLS proxy instance to handle the encrypted signaling.
ciscoasa(config)# tls-proxy my_proxy
Creates the TLS proxy instance.
ciscoasa(config-tlsp)# server trust-point
ciscoasa(config-tlsp)# server trust-point ccm_proxy
Specifies the proxy trustpoint certificate to present during TLS handshake.
The server command configures the proxy parameters for the original TLS server. In other words, the parameters for the ASA to act as the server during a TLS handshake, or facing the original TLS client.
Sets the local dynamic certificate issuer. The local CA to issue client dynamic certificates is defined by the
crypto ca trustpoint
command and the trustpoint must have
configured, or the default local CA server (LOCAL-CA-SERVER).
Where ldc issuer
specifies the local CA trustpoint to issue client dynamic certificates.
For client proxy (the proxy acts as a TLS client to the server), the user-defined cipher suite replaces the default cipher suite, or the one defined by the ssl encryption command. You can use this command to achieve difference ciphers between the two TLS sessions. You should use AES ciphers with the CallManager server.