Re-Thinking DDoS Defenses for TLS1.3

Encryption is one of the most valuable tools in our security arsenal. It enables us to ensure our privacy when online, when making mobile calls and it enables our personal information to be stored securely. Encryption enables us to exchange data confidentially, and it enables us (in many cases) to authenticate who or what we are exchanging data with. Encryption has helped us ‘trust’ the connected world, as it has infiltrated pretty much all aspects of our lives.

However, as we all know, encryption is not a solution to all of our security woes. It is used against us in ransomware, and some advances in encryption technology such as the latest version of the Transport Layer Security (TLS 1.3), can make identifying and blocking some threats more difficult.

Many network-based threat and fraud detection solutions have historically relied upon transparent, passive decryption of encrypted sessions via access to the server private key(s). With the introduction of TLS 1.3 this is not as simple, as all of the additional information needed to decrypt a session cannot be sniffed from the line. This technology dictates that as part of the cryptography process Perfect Forward Secrecy (PFS) key agreement protocols must be used to enhance the confidentiality of our communications – but this makes us re-think our mechanisms for dealing with another set of problems.

One area which does need to be re-thought is our mechanism for detecting and mitigating some forms of DDoS attack. The latest Worldwide Infrastructure Security Report (WISR) confirms attacks targeting encrypted web services have become increasingly common in recent years.

Specifically, in 2017, 53% of enterprise, government and education organizations detected attacks on encrypted services at the application layer. Application layer attacks use traffic that is very difficult to distinguish from genuine user traffic, often requiring analysis of the actual application layer transaction to identify the patterns of activity involved in an attack. Our approach to this process must change as TLS 1.3 is adopted.

The Sharing of Keys
One approach is to use a content distribution network (CDN) service, as these can be effective against application layer attacks. Where encrypted services are being protected this can mean the service owner handing over or generating private keys for use by the third-party provider. Whether this occurs or not, the CDN provider will terminate and decrypt customer communication within their environment for inspection. This can allow them to mitigate application layer DDoS attacks, yet other risks around confidentiality still remain.

Sometimes these risks are acceptable to end-customers and service owners, and sometimes not – leading to the second option of using an on-network reverse-proxy to do the job.

Using your own reverse-proxies is common for load-balancing, and they inherently allow traffic to be inspected. In an ideal world the proxy would provide telemetry to a DDoS protection solution so that attacking hosts could be identified and blocked, preventing resources being consumed on the proxy, as they are susceptible to state-exhaustion DDoS attacks.

State-exhaustion attacks target the ability of the proxy to manage sessions, and are unfortunately very common. This problem can easily be overcome by front-ending the reverse proxy with a DDoS protection solution that can identify and block both state-exhaustion attacks and those that target TLS negotiation.

However, there is a third option – transparent, passive decryption. But, hang on, didn’t we say TLS 1.3 made this impossible? As it turns out, passive decryption is still possible when using ephemeral Diffie-Helman ciphers, as used in TLS 1.3, if static keys are re-used across sessions, shared with on network security solutions through a key management platform and then periodically cycled. This mechanism allows transparent decryption of traffic, for threat identification and blocking, in a similar manner to existing pre TLS 1.3 mechanisms.

As with all things in security, different solutions will appeal to different organization based on their needs, those of their customers and prevailing regulatory requirements. However, with application layer DDoS attacks becoming ever more prevalent, an appropriate solution MUST be put in place.

Encryption is essential, and PFS undoubtedly improves the overall security of our interactions with the connected world, but we have to consider and overcome its impact to other elements of our defensive stack. This requires us to work across the IT, networks and security teams within our organizations to ensure we implement the most appropriate solution for our business.