I often get asked, “Why should we implement SSL inspection? We just upgraded our security from stateful inspection to deep inspection. If something is encrypted, is it not encrypted for a reason, for being secure?” Let me explain…
Back in the day, network traffic was well behaved. If you were a software vendor and wanted to offer a new application, you had to sign up with IANA and get a reserved port for your application. It is called a socket, the combination of a port number and a protocol such as TCP. The first firewalls were simple packet filters who controlled traffic to an application by controlling access to a socket. Firewalls evolved to stateful inspection, where you are not just controlling who has access to a socket but also the integrity of a TCP connection from the beginning of a proper handshake to closure. Once a connection is established, only this particular client and the application can communicate.
This whole paradigm changed when many more applications were developed than ports were available. Instead of applying for a new socket with IANA, software vendors zoned in on socket 80/TCP which is used by regular web servers. This also became a convenient port since most firewall policies would permit this port already. Recent Sonicwall research on customer networks shows that, today, over 90% of all connections use this port (or its cousin 443/tcp). The rest is mostly mail and DNS, and some voice-over-IP (VoIP) traffic. You may ask, “If everybody is using these two sockets, and I need to leave the socket open because a client could sit anywhere on the Internet (and for that matter a server could sit anywhere in the cloud), what is stateful inspection good for?” Exactly!
The security industry shifted towards deep inspection. Sonicwall was actually one of the very early players and evolved from SPI (Stateful Packet Inspection) to DPI (Deep Packet Inspection) over a decade ago, with many traditional security vendors only getting onto the bandwagon very recently. Deep inspection no longer cares about the socket, it cares about what data is transmitted, and whether it contains malicious content. With DPI, you can decide what applications do and do not go through your firewall. It is as granular as permitting Facebook, but denying “likes”, and does this regardless of which socket the application is using. DPI also protects from malicious content, both within the data stream as well as with embedded files, at a central network location.
What does this have to do with SSL inspection? SSL (Secure Socket Layer) is the most commonly used encryption technology on the Internet, as it allows virtually any client to build with any other server an encrypted connection, without building a prior trust relationship. Just like how SPI became less effective, DPI became less effective within the last two years. In order for DPI to look into traffic, it cannot be encrypted. Encrypted traffic looks to a firewall just like a random series of bits and bytes. If SPI became, to say it casually, “useless”, you see, the same happens to DPI right this very moment. Because all a malicious actor has to do is to encrypt the communication and can tunnel through the firewall, completely bypassing any security policy.
There are many reasons why this just happened overnight. For one, computers kept following Moore’s law, and became incredibly cheap and accessible. Malware is often distributed from breached machines, such as notebook computers, smart phones, or even the Internet of Things (such as your baby monitor). All of these devices can distribute encrypted malware while the performance impact on these devices is so minimal that the user will not notice. Another reason is that, with the Edward Snowden disclosures, many technology companies very vocally encouraged content providers to switch to encrypted traffic for pretty much anything in order to maintain citizen’s privacy from their own, or a different government. Now you add large operators of server farms to the mix, who can all be abused and (involuntarily) converted into malware distribution platforms, and you have the perfect storm. The firewall you “just” updated from SPI to DPI is on its way to become redundant as it becomes blind.
SonicWall calls SSL inspection DPI-SSL, which stands for Deep Packet Inspection of SSL encrypted traffic. Instead of the client, such as web browser, establishing an encrypted connection directly with a web server, DPI-SSL works by establishing an encrypted connection between the client and the SonicWall firewall. The SonicWall firewall then establishes an encrypted connection to the server so that the SonicWall firewall can inspect the traffic in-between. This all happens transparently and automatically, without user interaction, but with the user’s knowledge to maintain integrity.
But now you may be thinking: “I just upgraded to deep inspection. Now I have to invest into SSL inspection technology?” This is true for most vendors, unfortunately. Over half of all vendors require you to purchase a dedicated platform to perform SSL decryption and re-encryption services. We at SonicWall believe that many vendors did not take investment protection seriously three years ago, when they promised investment protection to you when you bought the deep inspection solution. SonicWall as the leader of DPI, recognizes the importance of SSL inspection as well as the investment customer made into DPI already. For this reason, SonicWall issues DPI-SSL licenses free of charge.
The good news is that DPI-SSL is not just free, but also already built into your SonicWall Gen-6 TZ, NSA, or Super Massive appliance. Stay tuned for my next blog, where we will discuss technical details and how you implement DPI-SSL into your network.
