Before we begin with the lesson, let's establish some context around the terms HTTPS, SSL, and TLS.

  • The term SSL stands for "Secure Sockets Layer." It is a network protocol that provides cryptographic security to data while in transit. SSL ver 1.0 was never released. Versions 2.0 and 3.0 were used for internet security in the late 90s and early 2000s. All versions of the SSL protocol have long been deprecated and not used.
  • The term TLS stands for "Transport Layer Security." TLS is simply a more secure version of SSL. Due to security flaws in SSL versions 2.0 and 3.0, SSL 3.1 was created and renamed to TLS 1.0. Since then, TLS versions 1.1, 1.2, and the latest 1.3 have been created and used for Internet security. However, people still refer to TLS as SSL to this day. 
  • HTTPS is just the HTTP protocol but with TLS encryption on top. However, the terms HTTPS, SSL, and TLS are often used interchangeably.

Why do we need an HTTPS/TLS proxy?

Nowadays, many organizations consume business-critical apps as-a-service over the Internet. As a result, most user traffic is HTTPS/TLS encrypted from an end client all the way to a server, as shown in figure 1 below. This end-to-end encryption prevents security devices from enforcing the organization's policy and may lead to hidden threats and malicious activities.

Why do we need HTTPS/TLS proxy?
Figure 1. Why do we need HTTPS/TLS proxy?

Cisco SD-WAN's TLS proxy feature allows us to set up an edge router as a transparent HTTPS/TLS proxy. The router performs TLS encryption and decryption as a man-in-the-middle between the client and the server, as shown in figure 2 below. It acts as the client from the server’s perspective and as the server from the client’s perspective. This allows the router to send the application traffic unencrypted to the Unified Thread Defense (UTD) for inspection and enforcement of the organization's policy. 

How HTTPS/TLS proxy improves security.
Figure 2. How HTTPS/TLS proxy improves security.

The term "transparent" proxy means that user traffic is redirected to the proxy at the transport layer without any explicit configuration on clients.

How TLS proxy changes the traffic flow?

When an edge router is configured to act as a TLS proxy, its behavior changes. The router intercepts TCP/HTTPS connections and interposes itself as a man-in-the-middle. If a TLS proxy policy is configured for this traffic flow, the ClientHello message is sent to the Unified Thread Defense (UTD). Based on the configured proxy action, the router takes the following action:

  1. do-not-decrypt:  If the configured action is "do-not-decrypt," the router drops out of the connection allowing the client and server to communicate directly.
  2. decrypt: If the configured action is "decrypt," the router interposes itself as a man-in-the-middle for this TLS connection and performs the following:
    1. TCP optimization.
    2. Decrypts the traffic and sends it for inspection to UTD.
    3. Reencrypts the traffic and forwards it along.
  3. drop: If the configured action is "drop," the ClientHello is discarded, and the connection is dropped.

When the configured action is "decrypt," the TLS proxy sends a ClientHello to the server and inspects the resulting ServerHello and Server Certificate. It answers the client with an Alternative ServerHello and issues a proxy SSL certificate. Depending on the configuration and the supported cryptographic ciphers, the proxy can renegotiate different encryption sessions with both ends. The client must trust the TLS proxy by installing the root CA certificate in its trust store (or by clicking through the certificate error.)

SSL/TLS Proxy Handshake
Figure 3. HTTPS/TLS Proxy Handshake

Figure 1 illustrates the TLS handshake process.

TLS Proxy and Certificate Authority (CA)

The Certification Authority (CA) plays a key role in the TLS proxying process. For the TLS proxy to be able to generate and sign proxy certificates, the CA must issue a signing certificate to each router acting as a TLS proxy. The router then stores the subordinate CA keys and can generate and sign certificates, as illustrated in figure 4 below.

TLS Proxy and Certificate Authority (CA)
Figure 4. TLS Proxy and Certificate Authority (CA)

There are four configuration CA options to choose from in vManage depending on the organization's PKI infrastructure:

  1. Enterprise CA
  2. Enterprise CA with SCEP Enabled
  3. vManage as CA
  4. vManage as Intermediate CA

Let's quickly list the pros and cons of each of the supported CA options.

Enterprise CA

If an organization already has its own PKI infrastructure that is used and trusted by clients, then the Enterprise CA is a good option.

  • Pros:
    • All organization certificates (SD-WAN and non-SD-WAN related) are managed through the same CA infrastructure, most likely by the same team.
    • Validity, expiry, and revocation of certificates are provided by the same CA.
    • The trust store doesn't need to be updated on clients. (assuming the enterprise CA is already trusted)
  • Cons:
    • If the Enterprise CA doesn't support SCEP (Simple Certificate Enrollment Protocol), certificates are managed manually. This includes generating a CSR for each router acting as a TLS proxy, signing the CSR by the CA, and uploading the signed cert to the router via vManage.
    • Reissuing expired certificates is also manual.
    • The network team has limited visibility into certificates via vManage.
    • Large blast radius if the enterprise CA gets compromised.

Enterprise CA with SCEP

This is an improvement from the previous option. It is a good choice for organizations that have their own PKI infrastructure.

  • Pros:
    • All benefits of the Enterprise CA option.
    • The deployment of certificates on the TLS Proxy routers can be automated.
  • Cons:
    • The network team has limited visibility into certificates via vManage.
    • Large blast radius if the enterprise CA gets compromised.

vManage as CA

If an organization does not have existing PKI infrastructure that includes a Certificate Authority, vManage can act as a CA.

  • Pros:
    • Automated certificate deployment to routers acting as a proxy.
    • Automated certificate reissuing before they expire.
    • Extensive visibility of certificates' validity, expiry, etc., via Cisco vManage.
  • Cons:
    • The Cisco vManage certificate needs to be pushed to the client trust store.

vManage as Intermediate CA

This option is a combination of the previous three. An organization with an existing CA may still want to use Cisco vManage as an intermediate CA. This allows vManage to issue and manage subordinate CA certificates of the root CA.

  • Pros:
    • Automated certificate deployment to proxy devices.
    • Automated certificate reissuing before they expire.
    • Extensive visibility of certificates' validity, expiry, etc., via Cisco vManage.
    • The Cisco vManage certificate doesn't need to be pushed to the client trust store. (assuming the Enterprise CA is already trusted by clients)
  • Cons:
    • If there are multiple vMange controllers in a cluster, the deployment could become very complex.

TLS Proxy Design Consideration

There are several design considerations to be made before an organization decides to implement a TLS Proxy. 

  • Since the proxy device interposes itself in the middle of HTTPS connections, flow symmetry is required in dual-homed branches.
  • Additionally, on dual-internet routers, the flows must be pinned to the same Internet link to ensure that the SSL client is NATed to the same source IP address.
  • Clients and the proxy must have their times in sync.
  • As you might guess, IPv6 is not supported.
  • TLS 1.3 is not supported. Connections that try to use TLS 1.3 are renegotiated (downgraded) to version 1.2.