What Is SSL Inspection? Why Use SSL Inspection?

magnifying-glass-above-gear

SSL Inspection or HTTPS Inspection is the process of intercepting SSL encrypted internet communication between the client and the server. The interception can be done between the server and the client and vice-versa.

We know that SSL encryption helps keep our data safe. Every bit of data is encrypted, such that data tampering or 3rd party intervention is not possible. However, that is not the case now. SSL can now be used to hide malware. 

That’s where SSL Inspection comes into the picture. SSL Inspection intends to filter out dangerous content, such as malware. This inspection is also called Deep SSL Inspection or Full SSL Inspection. It allows the user to do web and email filtering, antivirus scanning, etc.

You may also like: What Is SSL? How Do SSL Certificates Work?

How SSL Inspection Removes Malware

Basically, SSL uses an interception device between the server and the client. The interceptor device sits between the server and the client, and all the traffic goes through it. When the connection is made to the webserver, the interceptor intercepts all the traffic going through, decrypts it, and scans it.

Once the scanning is done, it forms another SSL connection with the client. So, the data is sent to the client via encryption.

SSL Inspection Overview

  • First, the interceptor intercepts the traffic coming and decrypts HTTPS sessions between clients and servers.
  • Once the traffic has been decrypted, the interceptor inspects the content through antivirus scanning, web filtering, etc.
  • Then, the interceptor encrypts the traffic and forwards it to the destination, in this case, the webserver.

In 2015, there was an incident involving a Lenovo PC, which was shipped with a preinstalled image advertisement optimizer developed by Superfish. Superfish is a form of adware that can hijack an encrypted web session and open a system up to potential HTTPS man-in-the-middle (MiTM) attacks, which implies that ads will be there in encrypted files.

Now, this allows a 3rd party to intervene and eavesdrop or modify the HTTPS secure communication; the amazing thing is that there will be no browser warning to the user. This mistake was made public and Windows released an update for Windows Defender, which removed Superfish.

However, this was not the first time that Superfish software was installed. Mozilla Firefox, Apple, and Microsoft Windows also expressed their concerns that Superfish was installed on their computers. 

Qualified personnel said that Superfish was not directly involved in the incident — a third party was involved behind the scenes. They found the code involved in the incident, and it was authorized by the tech company, Komodia. Komodia refers to its HTTPS-decrypting and interception software as an SSL hijacker and has been doing so since 2011.

Shortly after the Superfish incident, another piece of SSL interception software named PrivDog, made by Adtrustmedia, was also found to be vulnerable. PrivDog is an advertising program that intercepts HTTPS connections and replaces bad advertisements with advertisements approved by Adtrustmedia.

PrivDog is marketed as a solution to protect users against malicious advertising without completely blocking ads. To replace ads on websites protected with HTTPS, PrivDog installs a self-generated root certificate on the system and then runs as a man-in-the-middle proxy.

When users access the secured HTTPS sites, PrivDog hijacks their connections and replaces the legitimate certificates of those sites with new ones, signed by their own, with the locally installed root certificate.

Since the root certificate installed by PrivDog on computers is trusted by browsers, all certificates that chain back to it will also be trusted. This means that the users will think that they’re securely speaking to the websites they accessed, while in the background, PrivDog will decrypt and manipulate their traffic.

The only difference between PrivDog and Superfish is that Superfish’s mistake was that they used the same certificates across all deployments. PrivDog, on the other hand, copied the self-signed certificate of the user and signed it with their own trusted root certificate, thus forcing the browser to accept it.

But, PrivDog’s mistake was that they didn’t validate their certificates. Soon, PrivDog was caught and their methods were exposed to the public. 

Further Reading

This UrIoTNews article is syndicated fromDzone