Information about SSL/TLS Proxy
Overview of SSL/TLS Proxy
Note |
TLS is the successor of SSL. This document uses the term TLS to refer to both SSL and TLS. |
Today more and more apps and data reside in the cloud. As a result, majority of internet traffic is encrypted. This may lead to malware remaining hidden and lack of control over security. The TLS proxy feature allows you to configure edge devices as transparent TLS proxy. This feature has been integrated with Cisco Unified Threat Defense (UTD).
TLS proxy devices act as man-in-the-middle (MitM) to decrypt encrypted TLS traffic traveling across WAN, and send it to (UTD) for inspection. TLS Proxy thus allows devices to identify risks that are hidden by end-to-end encryption over TLS channels. The data is re-encrypted post inspection before being sent to its final destination.
Benefits of TLS Proxy
-
Monitoring of TLS traffic for any threats through transparent inspection
-
Enforcement of security polices based on the inspection of the decrypted traffic
-
Threat and malware protection for TLS traffic
Traffic Flow with TLS Proxy
A typical TLS handshake involves authentication using certificates signed by trusted, third-party Certificate Authorities (CAs). The clients and servers must trust these CAs in order to establish trust. TLS Proxy acts as MitM and runs a CA to issue proxy certificates for the connection dynamically.
This is how traffic flows when TLS proxy is enabled:
-
A TCP connection is established between the client and the proxy, and the proxy and the server.
-
If a decryption policy is enabled for the flow, a client Hello packet is sent to UTD to determine the decryption action.
-
Based on the UTD verdict, one of the following actions takes place:
-
drop: If the verdict is drop, the hello packet from the client is dropped and the connection is reset.
-
do-not-decrypt: If the verdict is do-not-decrypt, the hello packet bypasses TLS proxy.
-
decrypt: If the verdict is decrypt, the packet is forwarded to the client and goes through the following:
-
TCP optimization for optimization of traffic
-
Decryption of encrypted traffic through TLS proxy
-
Threat inspection through UTD
-
Re-encryption of decrypted traffic through TLS proxy
-
-
Note |
If there is a delay in determining the decrypt status of the flow, the UTD configuration for |
The following image shows the TLS handshake process.
Role of Certificate Authorities in TLS Proxy
About Certificate Authorities (CAs)
A CA manages certificate requests and issue certificates to participating entities such as hosts, network devices, or users. A CA provides centralized identity management for the participating entities.
Digital signatures, based on public key cryptography, digitally authenticate devices and individual users. In public key cryptography, such as the RSA encryption system, each device or user has a key-pair containing both a private key and a public key. The private key is kept secret and is known only to the owning device. The public key, however, can be known to everybody. The keys act as complements. Anything encrypted with one of the keys can be decrypted with the other. A signature is formed when data is encrypted with a sender’s private key. The receiver verifies the signature by decrypting the message with the sender’s public key. This process relies on the receiver having a copy of the sender’s public key and knowing with a high degree of certainty that it really does belong to the sender and not to someone pretending to be the sender.
How CA and TLS Proxy Work Together
Once you configure a CA for TLS proxy, the CA issues signing certificates to the TLS proxy device. The device then securely stores the subordinate CA keys, and dynamically generates and signs the proxy certificates. The TLS proxy device then performs the following certification tasks:
CA Options for Configuring TLS Proxy
The following CA options are supported for configuring TLS proxy:
-
Enterprise CA
-
Enterprise CA with SCEP Enabled
-
Cisco SD-WAN Manager as CA
-
Cisco SD-WAN Manager as Intermediate CA
Enterprise CA
Use this option to manage issuing certificates through an Enterprise CA or your own internal CA. For Enterprise CA that does not support Simple Certificate Enrollment Protocol (SCEP), manual enrollment is required. Manual enrollment involves downloading a Certificate Signing Request (CSR) for your device, getting it signed by your CA, and then uploading the signed certificate to the device through Cisco SD-WAN Manager.
Benefits |
Limitations |
---|---|
|
|
Enterprise CA with SCEP
Use this option to manage issuing certificates through an Enterprise CA or your own internal CA. If your CA supports SCEP, you can configure it to automate the certificate management process.
Benefits |
Limitations |
---|---|
|
|
Cisco SD-WAN Manager as CA
Use this option if you don't have an enterprise CA and want to use Cisco SD-WAN Manager to issue trust certificates.
Benefits |
Limitations |
---|---|
|
|
Cisco SD-WAN Manager as Intermediate CA: Benefits and Limitations
Use this option if you have an internal enterprise CA, but would like to use Cisco SD-WAN Manager as intermediate CA to issue and manage subordinate CA certificates.
Benefits |
Limitations |
---|---|
|
|
Supported Devices and Device Requirements
The following devices support the SSL/TLS Proxy feature.
Release |
Supported Devices |
---|---|
Cisco IOS XE Catalyst SD-WAN Release 17.2.1r |
|
Cisco IOS XE Catalyst SD-WAN Release 17.3.2 |
|
Cisco IOS XE Catalyst SD-WAN Release 17.4.1a |
|
Minimum Device Requirements
-
The device must have a minimum of 8 GB of DRAM; 16 GB for Cisco Catalyst 8300 Series Edge Platforms.
-
The device must have a minimum of 8 vCPUs.
Supported Cipher Suites
The TLS Proxy feature in Cisco Catalyst SD-WAN supports the following cipher suites.
-
TLS_RSA_WITH_3DES_EDE_CBC_SHA
-
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-
TLS_RSA_WITH_AES_128_CBC_SHA
-
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
-
TLS_RSA_WITH_AES_256_CBC_SHA
-
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
-
TLS_RSA_WITH_AES_128_CBC_SHA256
-
TLS_RSA_WITH_AES_256_CBC_SHA256
-
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
-
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
-
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
-
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
-
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
-
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
-
TLS_RSA_WITH_SEED_CBC_SHA
-
TLS_DHE_RSA_WITH_SEED_CBC_SHA
-
TLS_RSA_WITH_AES_128_GCM_SHA256
-
TLS_RSA_WITH_AES_256_GCM_SHA384
-
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
-
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
-
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
-
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
-
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
-
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
-
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
-
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Prerequisites for TLS Proxy
-
Flow symmetry is required for branches with dual routers.
-
If you have multiple internet links, the flows must be pinned to only one of them. This ensures that the sites that require an SSL client have the same source IP address.
-
TLS proxy devices and the clients must have their times in sync. See Configure NTP to learn how to synchronize all devices in the Cisco Catalyst SD-WAN solution.
Note |
Cisco recommends enabling TLS decryption only for encrypted traffic (for example HTTPS, SFTP) by creating a specific rule in the NG firewall policy. Unencrypted traffic should not be subjected to TLS decryption. |
Limitations and Restrictions
-
Only RSA and its variant cipher suites are supported.
-
Certificate Revocation List (CRL) check is not supported for server certificate validation. However, you can enable OCSP from Advanced Settings in SSL Decryption policy.
-
When a Cisco public key (PKI) certificate is installed on a device, and you want to make changes to the certificate, detach the security template from the device template and push the device template to the device. This will remove the existing PKI certificate and configuration. After you have made changes to the PKI certificate, re-attach the security template and then push the device template to the device. This process updates the device for any the changes to the Cisco PKI certificate.
-
OCSP stapling is not supported and must be explicitly disabled on the browser for the TLS session to be established.
-
For branch-to-branch and branch-to-data center traffic scenarios that support service nodes, the SSL decryption security policy must be applied in a way that prevents the SSL flow from being inspected on both the devices.
-
IPv6 traffic is not supported.
-
TLS session resumption, renegotiation and client certificate authentication are not supported.
-
If TLS proxy crashes, it takes up to two minutes for it to be ready to serve as proxy for TLS flows again. During this time, depending upon your security settings, the flows are either bypassed or dropped.