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 talks about scanning SSL traffic.
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.
The DPI on any firewall is used for two purposes:
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).
Based on the above examples, a certificate will be needed again for two purposes:
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 are going to use the DPI engine, the firewall will be signing each website you visit and changing 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.
Yes, an SSL certificate helps inspect all inbound and outbound traffic.
Deep Inspection of SSL is when data is decrypted and analyzed to see if it should be blocked and it is then re-encrypted.
Ideally, SSL Traffic cannot be inspected by any security gateway as it is encrypted. But there is an option of enabling HTTPS inspection wherein a new TLS connection is created and then the traffic can be decrypted and inspected.
If you want to see if your website or any other website that you are visiting has an SSL Certificate or not, you can check the URL. If the URL has an “S” after HTTP, then it indicates that the site is secure.
You can also get more information by checking the padlock icon beside the website URL.
If you want to view all certificates, press Win+R and type “certlm.msc”.
The certificate manager tool will appear. You’ll see that there’s a Certificate option on the left pane. Click on that and you’ll see a list of certificates that are available and click on the one that you want to view.
SSL Decryption allows you to have an in-depth look at the entire path not just an overview of the domain. Cyber attackers have learnt to encrypt and keep themselves undercover but decrypting the traffic helps have more control, more in-depth inspection and analysis, greater protection from malware threats, etc.
We keep uploading new blogs quite frequently on our website- keep an eye out for those.
Lastly, if you need help with more such IT Solutions, feel free to reach out to us. We’ll be happy to resolve your queries.