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.
…