Scan SSL Traffic

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

 

red padlock

 

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

 

https://en.wikipedia.org/wiki/Deep_packet_inspection

 

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,

common name on ssl certificate

 

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

 

Infrassist Admin
Infrassist Admin

Infrassist Technologies Pvt. Ltd, established in 2015, is a Master MSP that provides 24x7 professional IT Services to MSPs, globally. We are located in Ahmedabad, India and have a team of experienced engineers who have served 75+ MSPs across 15+ countries. We are an ISO 27001:2013 certified company, hence securing your data is our topmost priority. We provide 24x7 NOC services, Staff Augmentation and Professional services; wherein we provide consultation and carry out the implementation of various Microsoft 365 services.

Thanks For Reading