Most networks will contain a number of different security appliances and gateways. In this video, you’ll learn about SSL accelerators, SSL proxies, hardware security modules, and media gateways.
<< Previous Video: Mail Gateways Next: Software Security Tools >>
Let’s say you’re the manager of a web server farm that has hundreds of web servers. How do you maintain the security and encryption of data going through this network while also making sure the application runs efficiently? One way to do that is to use an SSL accelerator.
We use SSL accelerators because that handshake process for SSL uses a relatively large number of CPU cycles. If we can take that load and move it off of the web server and put it onto the SSL accelerator, the overall performance of the web server will be improved.
As you’re probably aware, SSL uses symmetric encryption to be able to encrypt the data between your browser and the web server. But getting that symmetric key to your device requires that an asymmetric communication be created first. That’s the SSL handshake. And that’s the part that takes the most number of CPU cycles. The SSL accelerator offloads that process to a separate device instead of using the web server. You may see this referred to as SSL offloading or SSL termination.
Depending on the configuration of the SSL accelerator, the actual communication that’s encrypted may end or terminate at the SSL offloading device. It may continue to the web server using in the clear HTTP. The exact configuration will vary between SSL accelerators, but it’s an important consideration when you’re planning the security and encryption of your applications.
Another common security technique is to use SSL decryption between your browser and a third party site. The SSL decryption device will decrypt the information, examine it for anything malicious, and then re-encrypt it to send it on its way. So if the communication between your browser and the third party website is encrypted, how is anyone able to decrypt what’s on the inside? Well the reason we’re able to make this happen is because of the trust relationship that your browser has with that third party site. Without that SSL or TLS relying on that trust, you wouldn’t be able to perform any type of decryption.
This all starts with your browser. There are a certain number of trusted certificate authorities that is already trusted by your browser. And it’s a list that’s constantly changing and constantly added to. Inside my browser is a list of about 170 different certificate authorities that are trusted. The browser will only trust a website if that web site certificate has been digitally signed by one of these trusted certificate authorities.
Normally a third party website will pay a certificate authority to sign their certificates so that anybody who accesses their website will have a signed certificate that’s already trusted by the browser. The idea is that the certificate authority has already gone through some type of checks to make sure that the person getting the signed certificate really is the appropriate person. Sometimes this is validation against the DNS record. Sometimes it’s a phone call. Or it could be other types of security checks as well.
When your browser connects to the third party website, it checks the web server certificate and looks to see who’s signed it. It then compares that signature with the known set of trusted certificate authorities that are already in the browser. And if it matches, then that particular website is trusted. If it doesn’t match, then your browser will normally display a message saying that this particular connection is not trusted and you should not continue communicating with that server.
To be able to decrypt the information going to this third party web site, you’re going to have to perform a proxy function. It’s usually provided on a firewall or some other type of SSL decryption device. Your user is communicating to this third party web site, professormesser.com. Inside the organization, this firewall has an internal certificate that has been created by the security people in your organization. And they’ve deployed that certificate to all of the devices that are inside of your company, including your laptop. When you connect to the web server, you’re sending the SSL handshake process. It is stopped by this proxy. And the proxy sends its own SSL handshake to retrieve the SSL handshake and public key information from the web server.
At that point, the SSL decryption device will create its own public key internally that is signed by the internal certificate authority. And since the internal certificate authority is trusted by your device, this SSL communication proceeds seamlessly without any additional messages on the screen. The only way that you would be able to tell if this was a proxied communication is if you were to look at the certificate details on your local machine. If it shows that it is an internal certificate, then you’ll know that there is a proxy that occurred somewhere along the way.
If you’re managing a large number of web server end certificates, you may want to implement a hardware security module or HSM. This is a high-end piece of hardware that’s designed to perform cryptographic functions. It’s usually a standalone device, although you can get a plugin card that would go into an existing firewall or proxy. This is also a place where you can backup all of your keys and keep them secure. It’s designed to be a protected storage repository for all of your web server certificates. An HSM might also act as an SSL endpoint so that some of that CPU overhead can take place on this server instead of your web servers. And we often see these implemented in large environments where there are many different web servers and many keys that have to be protected.
These days it’s common for an organization to have a media gateway in place that can connect from the public switched telephone network, or PSTN, and convert all of that to voice over IP to use internally with your voice over IP telephones. So there might be ISDN or a T1 trunk with the traditional telephone system on one side of the media gateway and an ethernet with voice over IP on the other side of the media gateway. There are many different combinations and configurations of media gateways, but this is also an important place to think about security for your voice network.
If someone does gain access to this device, they can disable all of your voice communication, which effectively would be a denial of service. Someone could get into the system and make their own outbound calls, which might be spam-type calls or malicious services. Or they might be able to listen in to the phone calls that are currently going through your media gateway. And if somebody’s trying to hear what a competitor is doing, this might be a very easy way to find out.