The “s” in https brought with it the promise of additional security. The padlock image inspired a sense of trust. Trust that our traffic is encrypted and no one else can intercept it. That data will not be eavesdropped into or tampered in transit. There is integrity and non-repudiation. We know whom we are communicating with.
But, do we really? Attackers have been quick to jump onto this bandwagon of trust and decided that if good traffic can be intercepted in transit so can malware.
Roughly 30% of today’s internet traffic uses SSL. By 2017, the percentage of SSL traffic is predicted to rise to 50% . Malwares like Zeus and Gameover have taken advantage of this in the past to launch DDOS attacks and steal financial information. Traditional firewalls are unable to decrypt and detect SSL encrypted malware.
Enter Next Generation firewalls and SSL Decrypts. In the traditional catchup game played between good guys and bad guys, the end user usually ends up in the thick of the action. With SSL decryption, that padlock might not be protecting you at all.
First let’s take a look at how SSL decryption is setup. It works in two ways: Inbound and outbound.
Inbound SSL traffic is relevant for internal sites or devices. The decrypting device would import a copy of the SSL certificate and private key to decrypt encrypted traffic in transit. The inbound packets are inspected for hidden malicious content and if it passes the test, traffic is forwarded onto the internal device in a secure manner.
Outbound SSL decryption uses the classic man in the middle scenario. The intercepting device generates a certificate based on the destination site certificate that the user is visiting. The user’s machine is configured to trust the interceptor within its own certificate store. An innocuous user, browsing pictures in facebook.com, transacting financial information at mybank.com or healthcare information at myuhc.com or any other site using https may not be aware that this traffic can be intercepted in transit within the enterprise perimeters.
Granted that SSL decrypting devices do have the option to turn on “do not intercept” based on the transactional nature of the website, this creates multiple potential points of failure. Depending on how the Decryptor is configured, an uncategorized website will decrypt personal information. A poorly configured decryption engine will add an additional point of failure for exposing and snooping on user information.
Along with the technical aspects, there appears a legal and ethical question. Is the enterprise user of today aware that there is no privacy on their system; will the security incident response be granted to tons of user personal information while investigating security incidents? Will the attacker still be able to smuggle malware through trusted SSL sites. In short will SSL become its own worst enemy?
At a minimum, if you implement an SSL decryptor for outbound traffic, you need to let users know of this up front. They may modify their behavior, but at least you are reducing the chance of being liable for injury to your users due to SSL decryption.
About the Author
Sammy Boss is a Visionary leader with strong skills in information security technologies, consensus builder, and an integrator of people, process and technology. He is currently a Security Solution Architect at the U.S. Department of Veterans Affairs.