Today, 99% of internet traffic is encrypted. With recent GDPR regulations, organizations are forced to use HTTPS making encrypted communication the default method. While traffic encryption is important for maintaining security and user privacy, it also opens the door to a new generation of aggressive DDoS attacks that can require up to 15 times more resources from the destination server than the requesting host.
Identifying malicious traffic within encrypted traffic is the tricky part. It’s equivalent to finding a needle in a haystack, which is why it’s an advantageous method for attackers because it puts significant computing stress on network and application infrastructures they target.
Ultimately, there is no one-size-fits-all solution for SSL protection. Each organization has its own unique priorities, business needs, sensitivities, and privacy needs. However, there are some guiding questions when selecting an SSL protection solution to consider in helping you find the best solution for your organization.
- Do You Have Access To The SSL Certificate?
For certain organizations, there is no access to the certificate. The reasons may be regulation or privacy restrictions, network and security architectural concerns, or Security as-a-Service (SaaS) models. When it comes to Managed Security Service Provider (MSSP) or scrubbing services, the end customer certificate may not be available.
Other organizations that have access to the SSL certificate can decrypt SSL traffic and gain visibility into the traffic.
2. If There Is Access To The Certificate, Where Should The Traffic Be Decrypted?
Having access to the certificate is one thing, the next consideration relates to network topology and the desired security.
In some network topologies, the decryption of SSL traffic is done closer to the servers, and in some deployments, it is preferable to decrypt the traffic sooner and eliminate threats early on. When the decryption is accomplished closer to the server, the protection typically relies on application protection solutions. In this case, one should keep in mind additional risks such as DDoS attacks that are better mitigated earlier in the network.
3. If There Is Access To The Certificate, When Should Traffic Be Decrypted?
Constant decryption of all SSL traffic allows full visibility but comes at the cost of computation and latency. For some, added latency cannot be afforded, meaning constant decryption of all sessions is not an option. Organizations would prefer a security solution that decrypts only under certain conditions, or decrypts some of the sessions, or in some scenarios no decryption at all. Decrypting less of the SSL traffic is key to achieve SSL security while balancing latency and legitimate user experience.
4. If There Is Access To The Certificate, What Part Of The Session Should Be Decrypted?
Similarly, to determine when to decrypt, one may wish to select the level of decryption. Decrypting only part of the SSL session rather than the full session has high value for protection from specific attacks. Same as the flexibility of when to decrypt SSL sessions, level of decryption can further assist organizations with balancing between desired security levels and an optimized user experience.
5. Are Your Services Overly Sensitive To Latency?
Decrypting all SSL traffic provides full visibility but involves significant computation overhead, thus increasing latency of the service. There are organizations and services that cannot afford the added latency of SSL decryption. Such organizations will need an SSL solution that does not require any decryption or minimum decryption, only under certain conditions, and only part of the sessions.
6. Do You Use Content Delivery Networks (CDNs) For Your Services?
When using a CDN, the CDN passes traffic on the organization’s behalf. In this case, the real IP address can be found only inside the encrypted HTTP headers, so there is no way of knowing the real client without decrypting all SSL traffic. With CDNs, the security solution must decrypt full SSL sessions, identify the real client in the HTTP headers and apply targeted security measures.
According to Radware’s Q2 2021 Quarterly DDoS Report, encrypted web attacks represent 20% of the total volume reported for all malicious events of the quarter. One thing is clear, traditional solutions don’t provide the necessary protections. Network-based solutions, such as Netflow Detectors, are blind to SSL traffic, making the network they operate in vulnerable to encrypted attacks.
If you’re using a Content Delivery Network (CDNs) is that it passes traffic on the organization’s behalf. The real IP address can only be found inside the encrypted HTTP headers, so there is no way of knowing the real client without decrypting all SSL traffic.
Other solutions require full decryption of HTTPS packets, thereby damaging user privacy, adding latency, and requiring a burdensome keys management process.