Inspecting TLS/SSL traffic on corporate networks is very common, as over 80% of all web traffic is encrypted. If you aren’t performing TLS/SSL traffic inspection, you are potentially leaving your network exposed.
The simple act of inspecting SSL connections helps reduce your attack surface. SSL inspection can make it harder to establish malicious outbound connections, such as malware trying to communicate with the C2 (Command and Control) server.
To reduce the attack surface further, I like to deploy a block on common file types that could be malicious, such as EXEs. If SSL inspection isn’t performed, any EXE downloaded via SSL won’t be blocked.
In this post, I will go over the basics of SSL inspection. I won’t go into details about certificate chains. If you want to understand more about certificate chains, my post Certificate Chain goes into more detail.
An SSL inspector sits in the middle of all SSL traffic, inspecting everything by decrypting and re-encrypting encrypted traffic on the fly. At its core, SSL inspection is like a MitM (man-in-the-middle) attack you control.
To inspect SSL traffic, the SSL inspector needs to decrypt it first. It can do this by tricking clients into communicating with it instead of the actual website, and the SSL inspector will communicate with the website on the client’s behalf. An SSL inspector is also a proxy.
To keep everything secure even when decrypting SSL traffic, the SSL inspector needs to be its own intermediate CA to resign and re-encrypt everything to send back to the client. All public-facing websites or web applications have certificates issued by a public root CA.
The SSL inspector can’t just issue certificates on behalf of a public root CA, as that would break the chain of trust. Even if you reach out to an intermediate CA, they will not sell you a certificate that could allow you to issue certificates on their behalf, even if it’s just for your internal network, as that also breaks the chain of trust.
To deploy an SSL inspector, you have two options. The first option is to deploy the certificate from your SSL inspector to all devices, making it and the certificates it issues trusted. The second option is to deploy your own internal root CA and allow your SSL inspector to be a subordinate CA (also known as an intermediate CA) and issue certificates on behalf of your internal root CA.
Deploying your own internal root CA is my preference, as SSL inspection is typically performed on corporate networks, and corporate networks typically have some sort of directory system (usually Active Directory or Entra ID (Azure AD)), which will allow you to automate the deployment of your internal root CA certificate very easily and quickly.
You won’t see the standard certificate chain on an SSL inspected network because the SSL inspector stands in the middle of your SSL traffic.
Let’s look at my website, thedxt.ca, and compare how the certificate chain looks on a non SSL inspected network to how the certificate chain looks on an SSL inspected network.
On a non SSL inspected network, the certificate chain begins with a server certificate for thedxt.ca issued by the intermediate CA GTS CA 1P5. The intermediate CA GTS CA 1P5 certificate is issued by the public root CA GTS Root R1, which is trusted, making the entire chain trusted.
The certificate chain on an SSL inspected network is slightly different. First, we have the regular server certificate, but that certificate is now issued by DXT-PA-FW-Sub-CA.dxt.local, which is the intermediate CA that is running on the SSL inspector. The intermediate CA DXT-PA-FW-Sub-CA.dxt.local certificate is issued by the internal root CA DXT-HO-NPS01-CA. The entire chain is trusted because the computer I am testing this on trusts the internal root CA DXT-HO-NPS01-CA.
The intermediate CA DXT-PA-FW-Sub-CA.dxt.local is my subordinate CA, which runs on my SSL inspector and issues certificates on behalf of my internal root CA, DXT-HO-NPS01-CA.
When the SSL inspector resigns and re-encrypts everything, if something is missing, like the intermediate CA certificate, the certificate chain is broken. This causes issues for the SSL inspector as it can’t rebuild everything correctly and will throw an error.
To learn more about what can cause broken certificate chains, my post, Broken Certificate Chain, dives into the details.
It’s also common for an SSL inspector not to inspect certain types of traffic, such as banking, financial, healthcare, and legal sites. The traffic you shouldn’t inspect depends on your organization and local laws.
Some applications will not work correctly if you SSL inspect their traffic. Those applications typically have documentation calling out what URLs should not be inspected. I have a list of items that various vendors recommended to exclude from SSL inspection on my GitHub. https://github.com/thedxt/SSL-Inspection
