Let’s take a typical enterprise. We have our internet connection going to our router (or ISP’s router), then handed off to our firewalls. We then break out to our internal and DMZ networks. Pretty standard stuff. We have our perimeter security controls sitting on the firewalls with a nice rule of “allow TCP port 443 (HTTPS) any to any.”
Now, we all know HTTPS is a secure protocol using SSL/TLS. Well, not quite secure. HTTPS is encrypted, sure, but what has been encrypted? Do our firewalls check the content of the encrypted traffic? Not by default, and in most cases, this is not even possible on firewalls. Our firewalls can do a great job of checking HTTP and other non encrypted protocols, but most will not or cannot inspect encrypted traffic (not without a reduction in performance, if they can do it at all). Stop and have a think about what could be hiding inside of HTTPS, running over your networks and on your PCs.
Is malware really an issue over HTTPS? Have a look at this blog post for some information that indicates this was a problem all the way back in 2008. This threat area has only been growing since then.
What can be done to look inside of encrypted packets so that our firewalls can do their job? The answer is SSL intercept. SSL Intercept (or SSL forward proxy) provides a way to inspect encrypted traffic. There are a few vendors that can do this. Your current firewall might be able to do this; Palo Alto Networks and Watchguard are two I know of that can. Some Application Delivery Controllers (ADCs) can also provide this function; A10 Networks and F5 are two that I know of. Be aware that when enabling SSL Intercept on firewalls, you will experience a big drop in performance on platforms that do not have dedicated hardware for encryption and decryption. This is where using ADC’s can offer better performance, as they are designed with SSL offload as a standard feature.
How can we implement SSL Intercept using ADCs and firewalls? The idea is to place SSL intercept devices around your firewalls if…
- they do not support SSL Intercept or
- if you want to offload the task of decryption and re-encryption from the firewalls.
In this way, we allow firewalls that can do perhaps 1 Gbps of HTTP protection to keep performing at their best, rather than drop down to ~400 Mbps when doing SSL intercept. Using the ADC’s will keep the firewall running at their top speed and allow all SSL traffic to be inspected.
Now, when a enterprise client makes a SSL connection, the inside ADC’s will terminate the SSL session by using a local certificate. Yes, you will need to push out that certificate to the trusted store on each PC, via group policy or maybe a login script for Linux machines. The traffic is then passed to the firewalls for cleaning. If the firewalls are happy with the traffic, a new SSL session is created from the outside ADC’s to the real servers. As traffic comes back from the servers, the reverse process happens.
The result is cleaned traffic! Of course, you will also need to have a whitelist that bypasses SSL intercept for certain situations. For example, I am sure people will not want you inspecting their banking transactions.