HTTPS/TLS proxy

Why inspection features go blind without it

Most web traffic is HTTPS, which is HTTP carried inside TLS (Transport Layer Security, the encryption protocol that replaced SSL). An IPS looks for attack patterns in the data. A malware scanner looks at files. A URL filter wants the path of a page. When the data is encrypted, all three see very little. The TLS proxy on the WAN Edge (cEdge/vEdge) exists to give those features something to read.

It does this as a deliberate man in the middle, with the organisation's permission. That one fact explains the certificate, the bypass list, the cost and the legal questions in the rest of this page.

The two sessions

1. A client in service VPN 10 opens a TCP connection to a web server and sends a TLS ClientHello that names the site.
2. The WAN Edge intercepts it and completes a TLS session with the client itself. To do that, it creates a certificate for the requested site name and signs it with the organisation's CA key.
3. The edge opens a separate TLS session to the real server and checks the server's own certificate.
4. Between the two sessions the data is in clear text on the router. The inspection features (IPS, URL filtering, file scanning) work on it here.
5. The edge encrypts the data again in each direction and forwards it.

The client does not talk to the server directly. If you look at the certificate in the browser, the issuer is your own CA. That is the visible sign that the proxy is working, and it is also the reason clients must trust that CA.

Which certificate the edge signs with

The edge needs a CA certificate and its private key, so that it can sign the per-site certificates in step 2. The options are described here at a high level. How you load them in SD-WAN Manager depends on your release, so check the current documentation.

Whichever you use, the client trust step is yours. Managed laptops usually receive the CA certificate through group policy or a device-management tool. Phones, printers, IoT devices and guest devices often cannot be given it, which is one reason they are bypassed.

What to decrypt and what to leave alone

Decrypting everything is rarely the right answer. A practical policy starts from the traffic that other controls need to inspect, and excludes the rest.

Site IDs and VPN numbers here are examples from the lab. The decision logic is what carries over.

Checking the server's certificate

Because the edge now makes the connection to the server, the edge is the one that must decide whether the server's certificate is acceptable. The user's browser can no longer judge it, because it only sees the proxy's certificate. If the server certificate is expired, self-signed, issued by an untrusted CA or for the wrong name, there are two choices:

• Block. Safer. Users may complain about internal or partner sites with sloppy certificates.
• Pass. Convenient, but the user loses the warning they would normally have seen. A risky site can look fine.

This is a design decision, not a technical default to accept. Check which behaviours and keywords your release offers, and write down the choice and who approved it.

What it costs

Decryption is the most demanding inspection task on the router. The edge performs two TLS handshakes per connection and encrypts and decrypts the data on top of the inspection itself. Expect higher CPU use, a little more latency per new connection and lower throughput than with inspection that does not decrypt. How much depends on the platform, the release and the traffic mix, so no figure is given here. Two things to check in the current platform documentation:

• whether your WAN Edge model supports the TLS proxy at all, and with what resources assigned to the security container or service;
• what throughput the vendor quotes with the proxy on, and under which test conditions.

Size from that data and from a trial, not from the datasheet figure for plain forwarding.

What it cannot proxy

• TLS versions and ciphers the proxy does not support. Such connections cannot be decrypted. The policy decides whether they pass or are dropped. Check the supported versions in your release.
• QUIC and HTTP/3. These run over UDP, usually port 443. A TCP-based proxy does not see them, so browsers that use QUIC can slip past decryption. Many designs block QUIC towards the internet so that browsers fall back to TCP and TLS, where the proxy works.
• Certificate-pinned applications. They fail when proxied. Bypass them.
• Mutual TLS (client certificates). The proxy cannot present the client's certificate to the server, so these connections generally need a bypass.

Legal and privacy questions to settle first

Decryption lets the organisation read employees' web sessions, including passwords typed on sites it did not intend to monitor. Before deployment, get advice on at least these points:

• whether staff must be told, and where (policy, contract, a banner);
• which categories local rules say must not be decrypted, and who holds the logs;
• how regulated data, such as card or health data, is handled when it passes through the proxy;
• who may access decrypted data and for how long it is kept.

This page gives no legal advice. The rules differ by country and by industry.

Rolling it out

1. Distribute the CA certificate to managed devices first, and confirm browsers on them trust it.
2. Start with a small pilot group in one service VPN at one site, for example a few users at BR-01.
3. Build the bypass list before the pilot, then add to it from what the pilot shows. Keep it in a reviewed document, not only in the configuration.
4. Watch for failures: new certificate errors, applications that stop, and a rise in tickets after the change.
5. Extend in stages. Watch router CPU and memory at each step.
6. Put the CA certificate expiry date in a calendar with a renewal task well ahead. An expired signing certificate gives every decrypted user a warning at once.

Checking that it is working

The exact commands and counters differ between releases, so this lesson avoids guessing keywords. Check in this order:

1. In SD-WAN Manager, confirm that the security policy with the TLS proxy is attached to the device template of the router, and that the template pushed successfully.
2. Confirm the router shows the security service as running. In the platform documentation, find the show command for the inspection service state in your release.
3. On a test client, open an HTTPS site that is in the decrypt scope. In the browser, check that the certificate issuer is your CA.
4. Open a site on the bypass list. The issuer must be the real public CA.
5. Review the router logs and the Manager monitoring pages for decryption failures and for the reason (unsupported version, certificate error, policy bypass).

BR-01#show utd engine standard status
Engine version      : (example)
Profile             : (example)
System memory       : (example)
Overall system status : Green

When a site breaks after the proxy is switched on

1. Does the problem affect only one site or application? Then suspect pinning, mutual TLS or an unsupported TLS version. Add it to the bypass list.
2. Does it affect every site for one device? That device does not trust the CA.
3. Does it affect every site for everyone? Check the CA certificate on the edge (expiry, chain) and the state of the inspection service.
4. Is it slow rather than broken? Look at router CPU and the volume decrypted. Narrow the scope.

Once decryption works, the web features can use it. Continue with URL filtering, which gets full paths from decrypted HTTPS, and AMP, which can scan files in decrypted downloads.

Test yourself on the TLS proxy