SSL Encrypted Traffic: Taking A Look Inside

First, what is SSL?

SSL stands for Secure Sockets Layer. It is a method of encryption commonly used with HTTP which is referred to as HTTPS. Almost every website now uses SSL for it’s connections, and if it doesn’t you may not want to visit it.

So, it is somewhat obvious, with it being a method of encryption as to why it is now preferred over HTTP. The not so obvious question though is; can everyone use HTTPS? The answer is yes. All it takes to establish a web server utilizing HTTPS is a certificate.

Certificates can be be created locally (self-signed) or purchased from a trusted third-party Certificate Authority (CA). These certificates can then be applied to the web-server and are used along with their public key to create an encrypted session. This is really a good thing; however, if you are an IT security professional, it causes a problem.

Typically in an organization you have hardware and software designed to protect your network. This technology lets you have visibility of everything going in and out. Prior to using HTTPS when the primary protocol was HTTP everything was in plain-text which made it very easy to inspect, for the good and bad guys. Now that it is all encrypted what do we do?

This is where SSL Inspection comes into play. Most modern security appliances offer the ability to intercept the HTTPS traffic and inspect it. So how does this work? Well, certificates are the key….literally. The security appliance uses its own set of certificates between itself and the client and the servers certificates between itself and the server.

The Pre-Inspection Inspection

The whole process summed up that way seems pretty straight-forward; however, there are some “gotchas.” The first one is that you must make sure that all certificates are validated and trusted. If there are invalid certificates then you open the door for some serious problems. The second, is that you need to know which clients you want to inspect traffic from so that you can install the public key of the security appliance. If your clients do not have a trusted relationship with the appliance no traffic will flow. Lastly, avoid self-signed certificates at all cost. Yes, it is easy and it is free, but the certificates are not publicly trusted and it only causes more trouble. Once your certificates are good to go you can move on to the inspection.

The Inspection

Looking at the image above it is clear that there are not too many steps involved. I will try to do my best to explain it in a bit more detail though.

Lets say you want to search Google for something. You enter the URL into your browser https://google.com and voila your there. What you did not see though was the verification that occurred between the client and server. When you hit enter the browser connected, but not to Google. Instead it connected to your security appliance. Since you should have already installed the public key for the appliance it created an encrypted session. The session was established using the public key to validate the servers private key, and a few other things. We don’t have to dive into that right now though.

But, wait why didn’t we connect to Google? Because the appliance needs the entire packet so it can decrypt it and analyze it. The data contains important data that identifies the application used. In this case it will also contain the exact URL that was requested. Once it has grabbed the data it re-encrypts it and sends it along via the session that it created with Google. With the network speeds we have you would almost never notice this. If you happened to do so, it would only be for a second and you would probably blame the IT guy anyway.