Many of us are familiar with Secure Hypertext Transfer Protocol (HTTPS) that uses a cryptographic protocol commonly referred to as Transport Layer Security (TLS) to secure our communication on the Internet. The benefit of securing our communication is obvious; however, the encrypted communication does have its downside.
To understand the downside, let’s see how the HTTPS communication is secured. In very simple terms, there are two keys, one available to everyone, called a public key and the other available to the recipient of the communication, called a private key. When you want to send encrypted communication to someone, you use their public key to secure that communication channel. Once secured, this communication can only be decrypted by the recipient who has the private key.
So, in normal usage, for example, let’s say you want to check your bank account. You’d use your browser to go to your online banking site; the communication channel you establish from you to your bank is secured with the bank’s public key. Your bank maintains its private key securely and is able to decrypt your request with their private key, verify you as a legitimate user and grant you access. From then on, all your communication on this channel is secure. There may be additional security procedures enabled as well.
The same mechanism of encryption using a public key can be used by malicious users/programs to gain access to sensitive information.
So, how can this happen? Consider a few scenarios: You inadvertently opened an infected file from someone possibly known to you, your computer was infected through a USB card that you shared, or through a malware that was embedded in some productivity program you downloaded.
When the malware activates, it may open an encrypted session to an external server. The only information the malware requires to secure the communication with the external server is the external server’s public key. Since the sending user/program’s organization does not have the private key to this encrypted communication, it’s unable to decipher this session and thus is blind to any information that’s being sent outside.
As usage of encrypted traffic increases, this challenge will become more pervasive. We are already beginning to see such cyber-attacks on many organizations for financial gain and for access to valuable confidential data.
Many traffic inspection solutions such as data leakage prevention (DLP), intrusion prevention systems (IPS), and firewalls may not have the ability to decrypt encrypted traffic, and therefore are blind to cyber threats initiated from within the organization to external servers. Even when they have the ability to decrypt, the ability comes with a performance impact, making these systems less scalable and thus un-economical.
The key to protecting against such attacks is to inspect SSL traffic. So, how does the SSL traffic inspection work?
The SSL inspection solution intercepts and decrypts SSL sessions destined to outside servers. For internal users/programs, these SSL inspection systems appear as the intended external server and for the recipient servers, the SSL inspection system appears as the user/program. The SSL inspection systems take advantage of the fact that the security is between two end points and not end-to-end.
For ease of deployment, SSL inspection systems may provide both transparent inspection without requiring the need to re-engineer the network or as explicit proxy that require all users to pass through a predefined SSL proxy configured via a user’s browser.
The decrypted traffic is then steered to any content inspection solution such as firewalls, anti-malware, or data leakage protection systems already deployed in the enterprise to check against an organization’s security policies. Sessions that pass the security inspection are then re-encrypted by the SSL inspection system and forwarded to its destination server.
For efficiency, some traffic may be sent through untouched if a particular site is trusted by the enterprise or is related to employee privacy (online banking, healthcare); others may be blocked for productivity reasons, typically online gaming or known malware servers.
To be secure yet cost-effective and efficient in gaining visibility to all encrypted traffic, it’s important to be selective in what encrypted traffic an organization decrypts.
Since SSL decryption and re-encryption are computationally intensive operations and may impact latency, use best practices – hardware acceleration if you have a large number of users and encrypted traffic; be selective with decryption by using filtering and whitelists to bypass decryption for sites that you trust, and choose solutions that reduce the number of devices you require to scale and are cost-effective.
For more details on Radware solutions: SSL Based Attack Protection
Read the ebook: “SSL Attacks on the Rise: Protective Technology Turned Attack Vector” to learn more.
Prakash Sinha is a technology executive and evangelist for Radware and brings over 29 years of experience in strategy, product management, product marketing and engineering. Prakash has been a part of executive teams of four software and network infrastructure startups, all of which were acquired. Before Radware, Prakash led product management for Citrix NetScaler and was instrumental in introducing multi-tenant and virtualized NetScaler product lines to market. Prior to Citrix, Prakash held leadership positions in architecture, engineering, and product management at leading technology companies such as Cisco, Informatica, and Tandem Computers. Prakash holds a Bachelor in Electrical Engineering from BIT, Mesra and an MBA from Haas School of Business at UC Berkeley.