Em 2011, a ferramenta THC-SSL-DOS demonstrou que um único laptop conseguia derrubar servidores HTTPS de grandes organizações. O mecanismo não era volumétrico: o atacante explorava a renegociação de sessão TLS para forçar o servidor a executar operações criptográficas assimétricas repetidas vezes na mesma conexão TCP. O custo computacional dessas operações é estruturalmente maior no servidor do que no cliente, porque o servidor executa exponenciação modular com chave privada extensa (no caso de RSA) ou geração de assinaturas ECDSA/Ed25519 (no TLS 1.3) para provar sua identidade a cada handshake.
A exaustão de handshake TLS/SSL é uma categoria de ataque DDoS que explora essa assimetria de custo. Em vez de gerar volume de rede, o atacante maximiza o consumo de CPU do servidor forçando o processamento de handshakes TLS repetidos — seja por renegociação em uma única conexão, seja por abertura massiva de novas conexões.
A assimetria matemática de custo
O handshake TLS é composto por operações criptográficas com perfis de custo radicalmente diferentes:
Operações baratas (simétricas, executadas por hardware dedicado): após o handshake, a transmissão de dados usa AES-GCM com suporte a instruções AES-NI. O custo marginal por byte é negligenciável.
Operações caras (assimétricas, executadas por software ou aceleradoras especializadas):
- Em protocolos até TLS 1.2 com RSA: o servidor realiza exponenciação modular com o expoente privado d, tipicamente de 1024, 2048 ou 4096 bits. A complexidade computacional cresce com o quadrado do tamanho da chave. Uma operação RSA-2048 requer centenas de multiplicações modulares de precisão arbitrária — algo que o atacante não precisa executar, pois a cifragem RSA com a chave pública é ordens de magnitude mais rápida.
- Em TLS 1.3 com ECDHE: o servidor realiza multiplicação escalar em curva elíptica para gerar o par efêmero de chaves Diffie-Hellman e, em seguida, gera uma assinatura ECDSA ou Ed25519 para autenticar o key share. O cliente apenas verifica essa assinatura — operação significativamente mais barata do que gerá-la.
Em benchmarks com openssl speed, a diferença entre operações de cifragem simétrica e assinaturas assimétricas abrange várias ordens de magnitude. Adam Langley documentou em 2010 que o Gmail processava handshakes SSL com menos de 1% de overhead de CPU adicional após otimizações — evidenciando que o custo bruto do handshake, sem essas otimizações, é o gargalo real.
A assimetria é estrutural: o cliente valida o servidor, mas o servidor faz o trabalho pesado de provar sua identidade.
Vetores de ataque
THC-SSL-DOS — renegociação em conexão única
O THC-SSL-DOS não abre e fecha múltiplas conexões TCP. Seu mecanismo é diferente e mais eficiente para o atacante:
- O atacante estabelece uma única conexão TCP persistente com o servidor.
- Completa o handshake TLS inicial normalmente — o servidor processa um handshake completo.
- Imediatamente após, envia um novo ClientHello de renegociação na mesma conexão, solicitando a renegociação dos parâmetros TLS.
- O servidor, obrigado pelo protocolo, executa um novo handshake completo sobre a mesma sessão TCP.
- O atacante repete o passo 3 centenas de vezes por segundo na mesma conexão.
O resultado é que uma única conexão TCP force N handshakes criptográficos completos no servidor, sem qualquer custo de estabelecimento de conexão TCP do lado do atacante. O RFC 5746 (Renegotiation Indication Extension) mitigou a dimensão de injeção de dados do ataque, mas não eliminou o custo de CPU da renegociação em si — até que o TLS 1.3 removesse a funcionalidade por completo.
TLS Handshake Flood — múltiplas conexões TCP
Este vetor é distinto do THC-SSL-DOS e opera da forma que intuitivamente parece o “ataque óbvio”:
- O atacante abre simultaneamente um grande número de conexões TCP novas.
- Inicia o handshake TLS em cada uma delas.
- Pode completar o handshake e fechar imediatamente, ou abandonar antes da conclusão.
- Repete continuamente para manter a pressão sobre o servidor.
A diferença-chave em relação ao THC-SSL-DOS: aqui cada handshake consome um socket e uma conexão TCP distinta. O TLS Handshake Flood é limitado pelo overhead de estabelecimento de conexão TCP e pelos limites de file descriptors do sistema operacional, tornando-o mais custoso para o atacante por handshake induzido no servidor.
TLS Session Ticket Flood e o risco das STEKs
Session Tickets permitem que o cliente retome uma sessão TLS sem handshake completo, apresentando um ticket criptografado pela STEK (Session Ticket Encryption Key) do servidor. Um atacante pode explorar esse mecanismo de duas formas:
A primeira é enviar session tickets inválidos ou fabricados em massa. O servidor precisa tentar descriptografar cada ticket com sua STEK antes de poder confirmar que ele é inválido — operação com custo não negligenciável de AES-CBC ou AES-GCM.
A segunda, mais sofisticada, surge quando a STEK é comprometida ou é fraca. Se o atacante obtiver a STEK (por exemplo, em implementações que usam a mesma chave por longos períodos sem rotação), pode fabricar tickets válidos que forçam o servidor a processar resumptions maliciosas em escala. O RFC 8446 recomenda rotação frequente de STEKs e uso de STEKs por instância para limitar o impacto de comprometimento.
Ataque por downgrade de cipher suite
O atacante negocia deliberadamente cipher suites com operações assimétricas mais custosas — como RSA 4096 bits em vez de ECDSA P-256 — maximizando o custo de CPU por handshake no servidor. Esse vetor é complementar ao TLS Handshake Flood: menor número de conexões simultâneas pode ser suficiente para saturar a CPU se cada handshake for artificialmente caro.
Encrypted Client Hello (ECH) e novos desafios
O Encrypted Client Hello (ECH), extensão do TLS 1.3, criptografa o ClientHello interno — incluindo o Server Name Indication (SNI) — usando uma chave pública do servidor distribuída via DNS (registro HTTPS/SVCB). O ECH melhora a privacidade do usuário, mas introduz um novo vetor de exaustão: o servidor precisa tentar descriptografar o ClientHello externo com sua chave privada ECH antes de determinar se o cliente é legítimo. Um atacante que envie ClientHellos ECH fabricados força o servidor a executar operações de decapsulamento HPKE (Hybrid Public Key Encryption) em massa — custo que não existia sem ECH.
A mitigação principal é rate limiting por IP de origem antes do processamento ECH e monitoramento de falhas de decapsulamento como sinal de ataque.
Comparativo: perfil de custo e superfície de ataque por versão TLS
| Protocolo | RTTs | Operação assimétrica do servidor | Renegociação | Superfície de exaustão |
|---|---|---|---|---|
| SSL 3.0 / TLS 1.0 | 2 | RSA: exponenciação modular com chave privada | Sim (vulnerável) | Alta — RSA lento + renegociação irrestrita |
| TLS 1.2 | 2 | RSA ou ECDHE + assinatura RSA/ECDSA | Sim (mitigado por RFC 5746) | Média — depende do cipher suite |
| TLS 1.3 | 1 | ECDHE + assinatura ECDSA/Ed25519 obrigatória | Não (removida) | Reduzida — sem renegociação, ECDHE eficiente |
| TLS 1.3 + ECH | 1 | ECDHE + ECDSA + decapsulamento HPKE | Não | Nova superfície via ClientHello fabricado |
Aceleração em hardware e métricas de capacidade (HPS)
A resistência de um servidor a ataques de exaustão TLS depende diretamente de sua capacidade de processamento criptográfico, medida em HPS (Handshakes Per Second):
Instruções AES-NI (disponíveis em processadores Intel e AMD desde 2010): aceleram operações AES-GCM usadas na transmissão de dados pós-handshake e na derivação de chaves de sessão. Não eliminam o custo das operações assimétricas do handshake em si.
Suporte a curvas elípticas em hardware (instruções MULX/ADCX/ADOX em Intel Broadwell+): aceleram a multiplicação escalar usada em ECDHE e ECDSA, reduzindo o custo das operações mais caras do handshake TLS 1.3.
Intel QuickAssist Technology (QAT): co-processador dedicado a operações criptográficas assimétrica RSA, ECDSA e operações de chave pública.
O openssl speed permite medir o HPS real de um servidor executando openssl speed ecdsa ecdhx25519 rsa2048 para comparar throughput por algoritmo. Em geral, ECDSA P-256 e X25519 (Curve25519) oferecem HPS muito superior a RSA 2048 no mesmo hardware.
Técnicas de mitigação
Terminação TLS no edge
A mitigação mais eficaz transfere o processamento do handshake TLS dos servidores de origem para nós de borda com hardware otimizado. O fluxo passa a funcionar assim:
Sem terminação no edge, cada cliente que acessa a aplicação força o servidor de origem a executar um handshake criptográfico completo. Em um ataque de exaustão, isso significa que o servidor de origem recebe diretamente toda a pressão criptográfica.
Com terminação no edge, os handshakes são encerrados nos nós de borda da rede de distribuição. O servidor de origem mantém apenas uma conexão TLS persistente com o edge — estabelecida uma única vez, não por cliente. O custo de handshake por usuário é eliminado completamente da origem.
Rate limiting por IP — antes e depois do handshake
O rate limiting de novos handshakes TLS por IP de origem interrompe ataques de TLS Handshake Flood. Para o THC-SSL-DOS (que usa uma única conexão), o controle relevante é o limite de renegociações por sessão — parâmetro configurável em OpenSSL (SSL_CTX_set_max_send_fragment) e em configurações de servidor como o ssl_renegotiate_size do nginx.
Session resumption com rotação de STEK
Session Tickets permitem que clientes legítimos evitem handshakes completos em reconexões, reduzindo a carga de CPU. A segurança do mecanismo depende da gestão correta das STEKs:
- Rotacione STEKs com frequência (a cada 24 horas ou menos em ambientes de alta sensibilidade).
- Use STEKs por instância de servidor — não compartilhadas entre nós — para limitar o raio de comprometimento.
- Aplique rate limiting de tickets inválidos por IP para mitigar Session Ticket Flood.
Desativar renegociação TLS (TLS 1.2 e anteriores)
Para servidores ainda usando TLS 1.2, desativar client-initiated renegotiation elimina o vetor THC-SSL-DOS original sem impactar usuários legítimos:
Em nginx: ssl_renegotiation off;
Em Apache: SSLRenegotiate off
Em OpenSSL direto: SSL_set_options(ssl, SSL_OP_NO_RENEGOTIATION);
Migração para TLS 1.3
O TLS 1.3 (RFC 8446) elimina a renegociação por design, reduz RTTs de 2 para 1 e padroniza ECDHE como único mecanismo de troca de chaves. Suportado por mais de 96% dos navegadores modernos, a migração elimina a maior superfície histórica de exaustão TLS. Veja também o que são cifras TLS e como afetam a segurança e performance do handshake.
Sinais de detecção
| Indicador | O que observar |
|---|---|
| CPU elevada sem tráfego HTTP proporcional | CPU a 100% mas throughput de dados baixo — típico de exaustão por handshake |
| Alto número de conexões TLS em handshake | ss -s ou openssl s_client revelando muitas sessões em estado handshaking |
| Queda no HPS (Handshakes Per Second) | Métrica de capacidade criptográfica abaixo do baseline histórico |
| Pico de falhas de session ticket | Alto volume de tickets inválidos por IP — sinal de Session Ticket Flood |
| Baixíssima taxa de requests HTTP concluídos | Conexões TLS estabelecidas mas poucas requisições processadas até o fim |
| Alertas de esgotamento de pool de threads TLS | Logs do servidor indicando impossibilidade de iniciar novos handshakes |
Erros comuns e soluções
Erro: Tratar exaustão TLS como um problema de volume de rede. Solução: Ataques de exaustão TLS consomem CPU, não largura de banda. Ferramentas de proteção volumétrica (baseadas em pps ou bps) não detectam nem mitigam esse vetor. O monitoramento deve focar em HPS e uso de CPU criptográfica.
Erro: Presumir que HTTPS é automaticamente “protegido” por usar criptografia. Solução: A criptografia assimétrica é exatamente a fonte da vulnerabilidade. Proteger HTTPS contra exaustão exige terminação TLS no edge e rate limiting de conexões e renegociações.
Erro: Não migrar de TLS 1.2 para TLS 1.3 por preocupações de compatibilidade. Solução: TLS 1.3 é suportado por mais de 96% dos navegadores modernos. A janela de incompatibilidade é mínima; o ganho de segurança e eficiência é substancial.
Erro: Usar RSA 2048 ou 4096 quando ECDSA está disponível. Solução: ECDSA P-256 oferece segurança equivalente a RSA 3072 com custo computacional muito menor por assinatura. A migração reduz o custo por handshake e aumenta o HPS do servidor.
Erro: Não rotacionar STEKs periodicamente. Solução: STEKs estáticas ampliam o impacto de um eventual comprometimento e facilitam Session Ticket Flood. Rotacione STEKs a cada 24 horas no mínimo.
Perguntas frequentes
Qual é a diferença exata entre THC-SSL-DOS e TLS Handshake Flood? THC-SSL-DOS usa uma única conexão TCP persistente e força múltiplas renegociações nela — cada renegociação é um handshake completo sem custo adicional de TCP para o atacante. TLS Handshake Flood abre múltiplas conexões TCP novas, uma por handshake. O THC-SSL-DOS é mais eficiente para o atacante por handshake induzido; o TLS Handshake Flood é mais fácil de executar em escala com botnet. O TLS 1.3 elimina o vetor THC-SSL-DOS ao remover a renegociação.
Por que o servidor executa a operação mais cara e não o cliente? No handshake TLS, o servidor precisa provar sua identidade gerando uma assinatura criptográfica com sua chave privada — operação que envolve exponenciação modular (RSA) ou multiplicação escalar em curva elíptica seguida de geração de assinatura (ECDSA/Ed25519). O cliente apenas verifica a assinatura com a chave pública do servidor, que é ordens de magnitude mais rápida. Essa assimetria é intrínseca ao design de infraestrutura de chave pública (PKI).
O que é HPS e como medi-lo?
HPS (Handshakes Per Second) é a métrica de capacidade criptográfica de um servidor — quantos handshakes TLS ele consegue processar por segundo antes de saturar a CPU. Meça com openssl speed ecdsa ecdhx25519 rsa2048 para comparar algoritmos, ou com ferramentas como wrk e h2load para medir HPS real com tráfego HTTPS simulado. Servidores com Intel QAT têm HPS substancialmente superior para operações RSA.
O que é ECH e por que cria nova superfície de ataque? Encrypted Client Hello (ECH) criptografa o ClientHello interno do TLS 1.3 usando HPKE (Hybrid Public Key Encryption). Isso melhora a privacidade do usuário ao ocultar o SNI de observadores de rede. O novo vetor de ataque: um atacante pode enviar ClientHellos ECH fabricados forçando o servidor a executar operações de decapsulamento HPKE em massa — operação computacionalmente não trivial — antes de determinar que o ticket é inválido.
Session Tickets podem ser explorados mesmo sem comprometer a STEK? Sim. Mesmo sem conhecer a STEK, um atacante pode enviar tickets fabricados (lixo criptográfico) em massa. O servidor precisa tentar descriptografá-los antes de confirmar que são inválidos — custo de AES-CBC/GCM por ticket. Rate limiting de tickets inválidos por IP é a mitigação principal.
O mTLS aumenta a superfície de exaustão? Significativamente. No mTLS, o servidor executa operações extras por handshake: verificação da assinatura do certificado do cliente, validação de toda a cadeia de certificados do cliente (que pode incluir CAs intermediárias), e — dependendo da configuração — consulta OCSP ou verificação de CRL para confirmar que o certificado do cliente não foi revogado. Cada uma dessas etapas adiciona custo criptográfico e, no caso de OCSP, latência de rede. Em ambientes mTLS de alta escala, aceleração de hardware e cache agressivo de respostas OCSP são essenciais para manter o HPS em níveis adequados.
O TLS 1.3 elimina completamente o risco de exaustão? Elimina o vetor de renegociação (THC-SSL-DOS). Mas o handshake inicial ainda requer ECDHE e geração de assinatura ECDSA/Ed25519 — operações com custo não negligenciável. TLS Handshake Flood ainda é possível contra TLS 1.3, porém o custo por handshake é menor do que com RSA-2048 ou RSA-4096, elevando o limiar de saturação. A eliminação da renegociação é o ganho mais significativo.
Como implementar na Azion
A Azion protege contra exaustão de handshake TLS com terminação TLS distribuída no edge:
- Terminação TLS nos data centers da Azion: Os handshakes TLS são encerrados nos data centers da Azion, não nos servidores de origem dos clientes. A origem nunca processa handshakes com usuários finais — mantém apenas uma conexão segura com o edge.
- TLS 1.3 por padrão: A Azion suporta e recomenda TLS 1.3, eliminando renegociação e reduzindo o custo por handshake e a superfície de ataque em relação ao TLS 1.2.
- Session resumption com gestão de STEK: A Azion implementa session tickets com rotação de chaves, reduzindo o custo de reconexões de clientes legítimos e mitigando Session Ticket Flood por volume e por IP.
- Rate limiting de conexões TLS: O edge da Azion aplica limites de novos handshakes TLS por IP de origem, bloqueando tanto TLS Handshake Floods quanto tentativas de renegociação em massa antes de consumir recursos de processamento criptográfico.
Saiba mais na documentação de Certificate Manager da Azion.