Guia de redução de latência TLS em Nginx: otimizar handshakes, OCSP stapling e ciphers em VPS com CPU baixa

Por Kevin Marcondes · Publicado em 28/10/2026 · 9 min de leitura

Este guia mostra, de forma prática, como reduzir a latência TLS em Nginx ao otimizar handshakes, OCSP stapling e ciphers em VPS com CPU limitada. Você verá decisões de compatibilidade, configurações exemplificadas e como medir ganhos. O foco é economizar ciclos de CPU sem sacrificar segurança, priorizando TLS 1.3, reuso de conexões e escolhas de curvas, certificados e cifras eficientes.

Por que o handshake pesa em VPS com CPU baixa

O handshake TLS faz operações criptográficas custosas: chave efêmera, verificação de certificado e geração de segredos. Em VPS com poucos vCPUs, cada nova conexão consome tempo e CPU. Reduzimos essa pressão com três frentes: diminuir o número de handshakes, baratear cada handshake e evitar validações externas desnecessárias.

A estratégia prática combina: TLS 1.3 + 1.2 bem escolhidos, ECDSA com fallback RSA, curvas rápidas, OCSP stapling correto, reuso de sessões e conexões, e um conjunto de ciphers compacto. Para completar, medições orientam os ajustes seguintes.

Se você ainda não tem automação de certificados, veja como obter SSL gratuito com Let's Encrypt em como gerar certificado SSL grátis.

• Diminuir o número de handshakes: keep-alive e session resumption.
• Baratear cada handshake: ECDHE com X25519 e ECDSA.
• Evitar validações externas: OCSP stapling com cache local.
• Medir e iterar: observar tempos de appconnect e erros OCSP.

TLS 1.3, curvas elípticas e certificados (ECDSA + fallback RSA)

TLS 1.3 reduz round-trips e simplifica ciphers. Mantenha TLS 1.2 para compatibilidade. Prefira curvas X25519 e P‑256, que são rápidas. ECDSA geralmente entrega handshakes mais leves que RSA. Carregar um certificado ECDSA e um RSA permite negociar o melhor para cada cliente.

A configuração abaixo ativa TLS 1.3 e 1.2, define curvas eficientes e carrega certificados ECDSA e RSA. Use caminhos reais dos seus arquivos e garanta a cadeia completa no certificado.

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519:P-256;
# ECDSA (principal)
ssl_certificate     /etc/ssl/certs/site_ecdsa_fullchain.pem;
ssl_certificate_key /etc/ssl/private/site_ecdsa.key;
# RSA (fallback)
ssl_certificate     /etc/ssl/certs/site_rsa_fullchain.pem;
ssl_certificate_key /etc/ssl/private/site_rsa.key;

OCSP stapling para cortar latência de validação

Sem stapling, o cliente consulta a CA, adicionando latência imprevisível. Com OCSP stapling, o servidor envia a prova de validade durante o handshake. Isso reduz espera no primeiro acesso e melhora confiabilidade.

Para funcionar, Nginx precisa do certificado raiz/intermediário confiável. Sem ssl_trusted_certificate, o stapling falha silenciosamente. Configure também um resolver confiável para baixar respostas OCSP.

• Verifique logs de erro do Nginx ao habilitar stapling.
• Renove certificados e monitore a validade da resposta OCSP.
• Evite resolvers muito lentos; isso afeta a atualização do OCSP.

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/ca_chain.pem;
resolver 1.1.1.1 1.0.0.1 valid=300s;
resolver_timeout 5s;

Reduzindo novos handshakes: keep‑alive e session resumption

Manter conexões vivas e reutilizar sessões TLS economiza CPU. Em sites com muitos recursos, isso reduz picos de uso e melhora o TTFB médio. Rotacione chaves de tickets com cuidado para não invalidar todas as sessões de uma vez.

Ajuste keep‑alive, cache de sessões e tickets. Em ambientes com múltiplas instâncias, compartilhe o ticket key entre nós para manter resumption após deploys.

• Keep‑alive reduz novos handshakes em navegações sequenciais.
• Session cache e tickets permitem retomar a sessão TLS.
• Rotacione tickets periodicamente e com sobreposição.

# HTTP keep‑alive
keepalive_timeout 60;
keepalive_requests 1000;

# TLS session resumption
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
# Gere e rotacione esta chave com segurança
ssl_session_ticket_key /etc/nginx/ticket.key;

Ciphers enxutos e ordem que favorece a CPU do cliente

Em TLS 1.2, mantenha apenas AEADs modernas. ChaCha20‑Poly1305 é ótimo em CPUs sem AES‑NI. AES‑GCM é excelente quando há aceleração. Lista curta acelera a negociação e evita armadilhas de compatibilidade.

Deixe a preferência do cliente decidir quando possível. Isso permite que dispositivos com AES‑NI usem AES‑GCM e, sem AES‑NI, escolham ChaCha20. Se você mede melhor resultado com ChaCha20 sempre, ative a preferência do servidor e coloque ChaCha20 primeiro.

• Remova DHE e ciphers legados (CBC/RC4).
• Mantenha ECDHE para forward secrecy.
• TLS 1.3 já define ciphers seguros por padrão.

# Para TLS 1.2
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
             ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
# Deixe o cliente decidir (bom para diversidade de hardware)
ssl_prefer_server_ciphers off;

0‑RTT (TLS 1.3): quando usar e como mitigar replays

0‑RTT corta um round‑trip em retomadas, mas permite replay. Use apenas para operações idempotentes, como GET de conteúdo estático. Nunca aceite 0‑RTT em endpoints que modificam estado.

O exemplo abaixo habilita 0‑RTT e retorna 425 quando métodos não seguros chegam com early data. Ajuste a lista se tiver endpoints explicitamente idempotentes.

# Bloqueie early data em métodos não idempotentes
map "$request_method:$ssl_early_data" $early_reject {
    "~^(POST|PUT|PATCH|DELETE|OPTIONS):1$" 1;
    default 0;
}
server {
    ssl_early_data on;
    if ($early_reject) { return 425; }
}

Outras alavancas rápidas: HSTS, HTTP/2 e nuances de deploy

HSTS evita redirecionamentos HTTP→HTTPS após a primeira visita. Isso não muda o handshake, mas reduz viagens extras. HTTP/2 consolida conexões e diminui novos handshakes em páginas com muitos recursos.

Em deploys, rotacione chaves de tickets com sobreposição. Monitore erros de stapling após a renovação de certificados. Para terminação TLS fora do Nginx, veja um exemplo com HAProxy em tutorial de HAProxy com Let's Encrypt.

• Ative HSTS com cuidado em domínios principais.
• Planeje rollback de tickets em janelas de baixo tráfego.
• Acompanhe logs do Nginx para OCSP e handshakes.

# HSTS (comece com um max‑age conservador)
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;

# HTTP/2
listen 443 ssl http2;

Como medir: tempos de handshake, stapling e compatibilidade

Meça antes e depois. Observe appconnect no curl. Verifique se o OCSP stapling está vindo do servidor. Confira versões e suporte do seu Nginx/OpenSSL. Em produção, repita testes de vários locais e dispositivos.

Para aprofundar TLS em Nginx e PKI, veja a base de mTLS em mTLS entre Nginx e serviços e a segurança geral em checklist de segurança para VPS.

• Execute múltiplas amostras e descarte outliers.
• Teste clientes com e sem AES‑NI (desktop vs mobile).
• Valide que o fallback RSA atende clientes antigos.

# Tempo até appconnect (handshake concluído)
curl -sS -o /dev/null -w 'connect=%{time_connect} appconnect=%{time_appconnect}\n' https://seusite.com

# Verificar OCSP stapling
openssl s_client -connect seusite.com:443 -status < /dev/null 2>/dev/null | sed -n '/OCSP response:/,/-----END/,/-----END/p'

# Conferir build
nginx -V 2>&1 | tr ' ' '\n' | egrep 'nginx|OpenSSL'

Checklist de priorização por impacto x risco

Use este quadro para decidir a ordem das mudanças. Comece pelo que rende mais em CPU/latência com baixo risco. Em seguida, avance para itens que exigem mais testes e observabilidade. Documente rollback para cada passo.

Perguntas frequentes

TLS 1.3 sempre reduz a latência do handshake?

Em geral, sim, pois simplifica a negociação e pode reduzir um round‑trip. Porém, mantenha TLS 1.2 para compatibilidade. O ganho real depende do cliente, da rede e do reuso de conexões e sessões no seu cenário.

Devo priorizar ChaCha20‑Poly1305 ou AES‑GCM nos ciphers?

Depende do hardware do cliente. Em dispositivos com AES‑NI, AES‑GCM é muito rápido. Sem AES‑NI, ChaCha20 costuma ganhar. Deixar a preferência do cliente decidir é uma abordagem segura. Meça no seu público.

OCSP stapling substitui a verificação do cliente com a CA?

Ele antecipa e envia a prova de validade no handshake, reduzindo a necessidade de consultas do cliente. Porém, o cliente ainda decide como validar. Configure ssl_trusted_certificate e monitore a atualização da resposta OCSP.

0‑RTT é seguro para APIs?

0‑RTT permite replay. Evite em endpoints que modificam estado. Se usar, limite a métodos idempotentes e considere tokens atrelados a nonce ou negar early data por padrão, retornando 425, e aceitar apenas em rotas muito específicas.

Session tickets ou session cache: qual escolher?

Use ambos. Cache compartilhado ajuda processos do Nginx. Tickets permitem retomada sem estado no servidor, úteis em ambientes escalados. Planeje a rotação de chaves de tickets e teste compatibilidade após renovações.

HSTS diminui a latência do TLS?

HSTS não afeta o custo do handshake, mas corta o redirecionamento HTTP→HTTPS em visitas seguintes. Isso reduz viagens extras e melhora o tempo total percebido pelo usuário após a primeira navegação.

Veja também

• Guia prático: como configurar failover ativo-passivo entre duas VPS com Keepalived, HAProxy e lsyncd para uploads sincronizados
• Guia: checklist técnico para preparar VPS Debian com Docker Compose para aplicações PHP em produção
• Guia prático para dimensionamento de VPS e tuning de PHP‑FPM para lojas Magento/OpenMage com picos sazonais: do sizing ao teste de carga
• guia prático: reconstruir índices no PostgreSQL em produção usando CREATE INDEX CONCURRENTLY e índices parciais (passo a passo seguro)