As today’s enterprises deploy more software to the cloud, while integrating software-as-a-service (SaaS) applications into their critical business infrastructure, the need for security and monitoring is obvious. With this need, SSL/TLS Decryption has become the security protocol designed to facilitate data security and privacy for internet communications. Heading into 2020, over 80 percent of internet traffic is being encrypted, including communication between web applications and servers, such as a web browser loading a website, to other communications such as email, messaging, e-commerce, banking, file storage, and voice-over IP (VOIP). Understanding how this affects your network performance and security strategy becomes imperative.
With the amount of today’s encrypted traffic, the importance of traffic inspection, balancing performance bottlenecks between tools, and protecting encrypted traffic is quickly becoming one of the top security architecture challenges.
SSL/TLS Decryption can seem complicated, so we’ll try to break this down and understand why to incorporate this into your security strategy.
SSL and TLS Decryption, What’s the Difference?
- TLS stands for “Transport Layer Security” and is the industry encryption standard, or cryptographic protocol that protects data exchanged over a computer network. When you type in a website into a browser, you may have noticed http://www... change to https://www.. , the “S” represents the updated TLS protocol, which is used to protect user data from network attacks. So websites or other web services using https, are employing TLS encryption. TLS is the updated version from the previous encryption protocol SSL.
- SSL decryption or “Secure Socket Layer” is a protocol for encryption-based internet traffic and verifying server identity (encrypted data exchanged) over IP networks. SSL, originally developed by Netscape, was replaced by the TLS as the standard in 2015, being a more secure alternative as security researchers discovered many vulnerabilities affecting SSL.
The terms TLS and SSL are commonly used interchangeably as a reference to decryption. Now that we have that down, it is key to start understanding the differences of TLS and TLS 1.3. Through the evolution from SSL to TLS 1.2, there was a focus on maintaining backwards compatibility, attempting to eliminate vulnerabilities which meant bad protocol design was inherited in the newer versions. After five years of design and testing by the Internet Engineering Task Force (IETF), the Transport Layer Security (TLS) protocol Version 1.3 was published in August 2018. TLS 1.3 drew the line in the sand, abandoning backwards compatibility for proper security design significantly improving performance, privacy and security.
>> Download now: IT Security [Whitepaper]
How SSL/TLS Decryption Works
SSL/TLS creates a secure channel between a users’ computer and other devices as they exchange information over the internet, using three main concepts: encryption, authentication, and integrity to accomplish this. Encryption hides data being transferred from any third parties. Authentication ensures the parties exchanging information are confirmed, while verifying the integrity of the data has not been compromised or tampered with.
At a high level, this is accomplished using a handshake process. The client and server agree on an encryption key, which cypher to use during the session. After the handshake both endpoints have a symmetric key, and all subsequent transmissions are encrypted.
TLS 1.3 speeds up the handshake process, helping to prevent breaches of the server’s key from being used to decrypt historical data. It also eliminates the use of RSA and other non-PFS public key exchange algorithms, while encrypting the certificates used for handshakes. With these advances, these changes also complicate decryption performed by security and monitoring tools.
Why SSL/TLS is Needed in Today’s Security?
Due to the significant growth in encrypted traffic it’s easy to see why decryption is critical to securing today’s enterprise networks. With growing blind spots forming in encrypted traffic, SSL/TLS sessions are increasingly used to conceal malware, hide command-and-control traffic and cloak the exfiltration of stolen data, inadvertently camouflaging malicious traffic. Effectively exploiting the very technology used to make user data and privacy more secure.
TLS-protected HTTPS is quickly becoming a standard practice for websites in order to protect web applications from data breaches and DDoS attacks. With most traffic now being encrypted many security teams and security tools do not have visibility into this traffic, creating one of the biggest blind spots in an enterprise architecture.
Architecting SSL/TLS to Maximize Performance
While protecting data through decryption is critical for many data sensitive industries, addressing blind spots, performance and network latency from decryption now becomes an issue for your security and monitoring tools.
Security tools including next-gen firewalls (NGFW), web application firewalls (WAF), web security gateways, IPS and data-loss prevention systems, all need the proper traffic to function and protect. While most tools may offer decryption capabilities, this “built-in” functionality leads to straining performance and introducing latency. Each device running decryption and encryption is processor-intensive, taking away resources from the security tools main function, adding latency and slowing the user experience.
These issues also persist in out-of-band and cloud analytics and performance monitoring tools. Hidden packet header and payloads, obscure performance, behavior, and trend data measurement and analysis.
Internal bypass software sounds good in theory, but if the device goes down, you still have to replace it and take the link down, creating a single point of failure. Not to mention adding internal or built-in bypass options to your inline tool tends to cost more than your external option. An external bypass prevents that SPOF possibility, while also providing a host of benefits. No maintenance windows, imagine that. Operation isolation and tool sandboxing means you can easily take tools out-of-band for updates, installing patches, maintenance or troubleshooting to optimize and validate before pushing back inline.
Looking to add inline security solutions, but not sure where to start? Join us for a brief network Design-IT consultation or demo. No obligation - it’s what we love to do.
