Scan SSL Traffic: What you should know and how should you do?
Most of the traffic passing through your network firewall these days is over SSL (Secure Socket Layer) or HTTPS. Which means that it is encrypted in nature. And at some point, all IT Admins and MSPs (Managed Service Providers) have come through a question from the client which needs DPI (Deep Packet Inspection) to be implemented to be able to get full visibility of the traffic. This blog will show you, how you can scan your SSL Traffic.
10 min read, 30-60 mins implementation with testing
Before we go further, let us understand the biggest downside of the scanning and the error most users complain about. Invalid certificate or red padlock icon in the browser wherein, the browser shows error and needs us to click on either the advanced tab or proceed to unsafe website. This by far is the biggest challenge we face in day-to-day administration.
Where does DPI come into the picture?
The DPI on any firewall is used for two purposes:
- To identify apps communicating over SSL
- For websites that use HTTPS.
For Apps that use SSL, the DPI engine on any firewall would subject the traffic to an internal proxy engine. The proxy engine inside the firewall needs to see the traffic in plain text form. Accordingly, it decides whether to allow or drop the connection. Hence, when using the DPI engine, two tunnels are created – one from the end-user computer to the firewall. Second from the firewall to the actual IP/website. As opposed to a normal connection where there will be end-to-end encryption with only one tunnel.
The approach with HTTPS websites is no different but there exists another method wherein the traffic can be done away with, without DPI scanning. This is done with the help of the common name on the certificate and DNS request. As we know, every client will request the IP address of the domain name it wants to browse with the DNS server.
For the DNS approach, you must ensure that all outside DNSs are blocked. The only DNS that an internal user can use to query must be the firewall.
For the common name approach, when the website responds to the HTTPS request, it sends the certificate information which has the common name (the website to which the certificate was issued). This information can be used to make a decision by the proxy engine to allow or drop the connection. However, the approach in both of the above cases is limited.
Let us see how a common name on the certificate looks like,
As seen in the screenshot above, the common name on the certificate is *.google.com. This is a good example showing the limitation of the DNS and common name-based approach. The proxy engine knows that the user is trying to browse some google service. However, it remains unknown until traffic is subjected to the Deep Packet Inspection. Similar certificates will be available if the end-user browses Gmail (Web-Email category), Google Drive (Storage category), Hangouts (Chat category), YouTube (Streaming category).
How to get rid of the SSL certificate errors?
Based on the above examples, a certificate will be needed again for two purposes:
- For the firewall management portal including any end-user portal and other service portals
- For web proxy
Let’s take the case of the firewall management portal. Since this is presented to the user as a website, the browser checks URL match against the common name on the certificate. Most firewalls will have a self-signed CA (Certificate Authority) on them which will allow you to generate multiple certificates. Since these CAs are self-signed, their certificate chain and Root CA will not be trusted in the browser which results in the red padlock.
You can buy a certificate from any certificate distribution like GoDaddy, Let’s Encrypt, Comodo certificate and many more. But the certificate common name will have to match the URL you are opening in the browser.
For instance, you get a certificate for firewall.companyname.com, the firewall IPs must point to firewall.companyname.com. This can be done with the help of Zone editor on the web host (cPanel, etc.) side and Internal DNS or firewall DNS for the internal IPs.
If you use the DPI engine
If you are going to use the DPI engine, the firewall will be signing each website you visit and change the root CA to its root CA (as this is another tunnel between the end-user machine and firewall). To overcome red padlock errors in this stage, you can either trust the firewall root CA in all the browsers or buy a CA ( Authority) certificate.
However, this option is very expensive as getting an authority certificate practically means you can sign any certificate. Every country has its local laws on defining who root CAs can be and it requires much documentation and compliance.
Concisely, if DPI scanning is a priority, one should be looking at the ways they will push the root CA to be trusted in all the client browsers (domain computers, guests, mobiles, and more). Now, this can be done is by hosting it in a shared place that can be accessed by all devices.
Finally, thanks for taking the time to read the article. We hope this enlightens you more about how you can scan your SSL traffic. Please share and let us know any other topics/articles you would like to see from our team of experts.