TLS na prática: configurações, versões, cipher suites e validação

TLS (Transport Layer Security) é o protocolo mais comum para proteger dados em trânsito em aplicações web, APIs, mensageria e diversos serviços internos. Na prática, “usar TLS” não é uma decisão binária: a segurança real depende de versão, cipher suites, parâmetros (curvas, grupos DH), certificados, validação do servidor (e às vezes do cliente), além de detalhes operacionais como SNI, ALPN, renegociação, reuso de sessão e observabilidade. Este capítulo foca em como configurar e validar TLS de forma pragmática, evitando armadilhas frequentes.

O que o TLS entrega na prática (e o que depende de configuração)

Em uma conexão TLS bem configurada, você obtém: confidencialidade (tráfego cifrado), integridade (detecção de alteração) e autenticação do servidor (o cliente confirma que está falando com o servidor certo). Em alguns cenários, também há autenticação do cliente (mTLS). O “bem configurada” é crucial: versões antigas, suites fracas, validação incompleta de certificados ou aceitação de parâmetros inseguros podem reduzir ou anular essas garantias.

Do ponto de vista operacional, TLS também influencia desempenho e compatibilidade: TLS 1.3 reduz rodadas de handshake e simplifica suites; TLS 1.2 ainda é necessário para compatibilidade com clientes legados; e a escolha de suites e curvas afeta CPU, latência e suporte em bibliotecas.

Versões de TLS: o que habilitar e o que bloquear

TLS 1.3

É a versão recomendada quando disponível. Ela remove algoritmos legados, reduz complexidade e define um conjunto menor de opções perigosas. Em TLS 1.3, as cipher suites não incluem mais o algoritmo de troca de chaves (sempre efêmero) nem o de assinatura; elas basicamente selecionam o AEAD e o hash associado. Isso reduz o risco de combinações ruins.

• Habilite TLS 1.3 sempre que possível.
• Prefira suites AEAD modernas (AES-GCM ou ChaCha20-Poly1305).
• Garanta suporte a grupos ECDHE modernos (por exemplo, X25519 e P-256).

TLS 1.2

Ainda é amplamente usado. Pode ser seguro, mas exige mais cuidado: você precisa restringir suites, garantir ECDHE (chaves efêmeras), evitar CBC e evitar RSA key exchange. TLS 1.2 também tem mais variações de handshake e extensões, aumentando a superfície de erro.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Mantenha TLS 1.2 habilitado se você precisa suportar clientes que não falam TLS 1.3.
• Restrinja a suites ECDHE + AEAD (GCM ou ChaCha20-Poly1305).
• Desabilite RSA key exchange e suites CBC.

TLS 1.1, TLS 1.0 e SSL

Devem ser desabilitados. Além de vulnerabilidades conhecidas e limitações criptográficas, eles forçam compatibilidade com suites e parâmetros obsoletos. Em ambientes internos, às vezes ainda existem clientes legados; nesse caso, trate como dívida técnica com prazo e plano de migração, isolando o legado (por exemplo, via um proxy dedicado) em vez de enfraquecer o serviço principal.

# Regra prática de versões (servidor): habilitar apenas TLS 1.2 e 1.3

Cipher suites: como escolher sem cair em listas intermináveis

Cipher suite é um “pacote” de algoritmos e parâmetros que define como a sessão será protegida. A escolha correta depende da versão do TLS.

Em TLS 1.3

As suites comuns e recomendadas são:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256

Critérios práticos:

• AES-GCM é excelente quando há aceleração de hardware (muito comum em servidores modernos).
• ChaCha20-Poly1305 costuma ser melhor em dispositivos sem aceleração AES (muitos celulares e IoT), e também é uma boa opção geral.
• Não tente “otimizar” escolhendo dezenas de suites: em TLS 1.3, poucas suites bem escolhidas bastam.

Em TLS 1.2

Aqui a lista é mais sensível. O objetivo é: ECDHE (sigilo futuro) + AEAD. Exemplos de suites recomendadas (nomes podem variar por biblioteca):

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

O que evitar em TLS 1.2:

• RSA key exchange (ex.: TLS_RSA_WITH_...): não oferece sigilo futuro e é um alvo comum de downgrade/legado.
• CBC (ex.: ..._CBC_...): historicamente sujeito a classes de ataques e exige mitigação cuidadosa.
• 3DES, RC4 e qualquer suite “EXPORT”: obsoletos.

Ordem de preferência: em muitos servidores você pode definir a preferência do servidor. Uma prática comum é priorizar AES-GCM e oferecer ChaCha20-Poly1305 como alternativa, permitindo que clientes escolham ChaCha quando for melhor para eles (alguns stacks escolhem automaticamente com base em performance).

Parâmetros de troca de chaves: grupos e curvas

Mesmo com suites corretas, você precisa garantir que os grupos (curvas elípticas e/ou grupos DH) sejam seguros e compatíveis. Em TLS 1.3 isso aparece como “supported groups”. Em TLS 1.2, aparece como “elliptic curves” e “DH params”.

• Prefira X25519 e P-256 como baseline de compatibilidade e segurança.
• Evite grupos DH fracos ou parâmetros DH compartilhados inseguros. Se você ainda usa DHE (não ECDHE), use parâmetros fortes e gerados corretamente, mas na prática ECDHE é o padrão.
• Desabilite curvas raras/legadas que aumentam superfície de compatibilidade sem benefício.

# Regra prática: habilitar X25519 e P-256; manter P-384 apenas se necessário

Certificados e cadeia: o que configurar no servidor

O servidor apresenta um certificado e, normalmente, uma cadeia intermediária. Erros comuns aqui quebram clientes ou abrem brechas de validação.

Checklist de certificado no servidor

• Nome correto: o certificado deve cobrir o hostname usado pelo cliente (SAN). Não dependa de CN.
• Cadeia completa: entregue o certificado do servidor + intermediários necessários. Não inclua a raiz.
• Algoritmo de assinatura: use certificados com assinaturas modernas (por exemplo, ECDSA ou RSA com tamanho adequado). Evite SHA-1.
• Rotação: planeje renovação antes de expirar e automatize emissão/instalação quando possível.

OCSP stapling (quando aplicável)

OCSP stapling permite que o servidor “anexe” uma prova de status de revogação, reduzindo latência e dependência do cliente em consultar o CA. Nem todos os ambientes exigem, mas é uma melhoria prática quando bem suportada.

• Habilite stapling se seu servidor/proxy suporta de forma estável.
• Monitore falhas de atualização do OCSP para evitar indisponibilidade.

Validação no cliente: onde muita gente erra

Grande parte dos incidentes com TLS vem de validação fraca no cliente: aceitar qualquer certificado, desabilitar verificação “temporariamente”, não validar hostname, ou confiar em CAs indevidas. O cliente deve fazer duas validações essenciais: (1) a cadeia até uma âncora confiável e (2) o hostname.

Passo a passo: validação correta do servidor (cliente)

• Passo 1: use a validação padrão da biblioteca. Evite implementar validação manual de X.509.
• Passo 2: valide hostname. Garanta que o hostname do URL/endpoint é o mesmo que você passa para a conexão TLS (SNI) e que a biblioteca verifica SAN.
• Passo 3: trate erros como fatais. Certificado expirado, hostname mismatch, cadeia incompleta, assinatura inválida: não “faça fallback” para HTTP nem ignore.
• Passo 4: pinning (opcional e com cuidado). Pinning pode ser útil em apps móveis ou ambientes controlados, mas aumenta risco operacional (quebra em rotação). Se usar, prefira pinning de chave pública (SPKI) com estratégia de rotação (pins de backup).

# Anti-padrões (cliente): desabilitar verificação, aceitar qualquer certificado, ignorar hostname mismatch

mTLS: autenticação do cliente com certificados

Em mTLS, além do servidor ser autenticado, o cliente também apresenta certificado. Isso é comum em comunicação serviço-a-serviço, B2B e ambientes regulados. Na prática, mTLS exige gestão de identidade e autorização: o certificado do cliente prova “quem é”, mas você ainda precisa mapear isso para permissões.

• Defina quais CAs emitem certificados de cliente e restrinja a trust store do servidor.
• Valide atributos relevantes (SAN/URI, OUs, políticas) conforme seu modelo de identidade.
• Planeje revogação/expiração e rotação de certificados de cliente.

Configuração prática em servidores comuns (exemplos)

Os exemplos abaixo mostram intenções de configuração. Ajuste conforme sua distribuição, versão do servidor e requisitos de compatibilidade. O objetivo é: TLS 1.2/1.3, suites modernas, parâmetros seguros e headers/ALPN quando aplicável.

Nginx (exemplo de baseline)

server {    listen 443 ssl http2;    server_name api.exemplo.com;    ssl_protocols TLSv1.2 TLSv1.3;    ssl_prefer_server_ciphers on;    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';    ssl_ecdh_curve X25519:P-256:P-384;    ssl_certificate     /etc/ssl/certs/fullchain.pem;    ssl_certificate_key /etc/ssl/private/privkey.pem;    # OCSP stapling (se suportado e testado)    ssl_stapling on;    ssl_stapling_verify on;    resolver 1.1.1.1 8.8.8.8 valid=300s;    resolver_timeout 5s;    location / {        proxy_pass http://app_backend;    }}

Pontos de atenção:

• ssl_protocols restringe versões.
• ssl_ciphers afeta principalmente TLS 1.2; TLS 1.3 usa suites separadas em versões recentes do Nginx/OpenSSL.
• ssl_ecdh_curve define grupos preferidos.
• Teste com clientes reais e scanners para confirmar o resultado efetivo.

Apache HTTPD (exemplo)

SSLProtocol             -all +TLSv1.2 +TLSv1.3SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305SSLHonorCipherOrder     onSSLCertificateFile      /etc/ssl/certs/fullchain.pemSSLCertificateKeyFile   /etc/ssl/private/privkey.pem

HAProxy (exemplo)

frontend fe_https    bind :443 ssl crt /etc/ssl/private/site.pem alpn h2,http/1.1 ssl-min-ver TLSv1.2 ssl-max-ver TLSv1.3    # TLS 1.2 cipher list (varia por versão)    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256    default_backend be_app

Passo a passo: endurecimento (hardening) de TLS em um serviço

Um processo repetível evita “configuração por tentativa e erro”. Use este roteiro para um endpoint HTTP(S) típico; adapte para SMTP/IMAP, gRPC, bancos e outros protocolos.

Passo 1: inventariar clientes e requisitos de compatibilidade

• Liste quem consome o serviço: browsers modernos, apps móveis, parceiros B2B, serviços internos.
• Identifique clientes legados que exigem TLS 1.2 apenas ou suites específicas.
• Defina um baseline: “TLS 1.3 + TLS 1.2 restrito”.

Passo 2: definir versões e suites

• Habilite TLS 1.3 e TLS 1.2; desabilite o resto.
• Em TLS 1.2, permita apenas ECDHE + AEAD.
• Em TLS 1.3, mantenha as suites padrão recomendadas.

Passo 3: configurar grupos/curvas e parâmetros

• Priorize X25519 e P-256.
• Evite DHE com parâmetros fracos; se não precisar, prefira ECDHE.

Passo 4: configurar certificado e cadeia

• Instale fullchain (servidor + intermediários).
• Verifique SANs e validade.
• Automatize renovação e reload do serviço.

Passo 5: habilitar ALPN (HTTP/2, gRPC) quando necessário

ALPN negocia o protocolo de aplicação (por exemplo, HTTP/2). Sem ALPN, clientes podem cair para HTTP/1.1 ou falhar em gRPC. Garanta que seu proxy/servidor anuncia h2 quando aplicável.

Passo 6: testar com ferramentas e com clientes reais

Faça testes automatizados e manuais. Exemplos com OpenSSL (ajuste host/porta):

# Ver detalhes do handshake e certificadoopenssl s_client -connect api.exemplo.com:443 -servername api.exemplo.com -showcerts# Forçar TLS 1.2 para ver suites negociadasopenssl s_client -connect api.exemplo.com:443 -servername api.exemplo.com -tls1_2# Forçar TLS 1.3openssl s_client -connect api.exemplo.com:443 -servername api.exemplo.com -tls1_3

O que observar nos resultados:

• Versão negociada (1.3 preferencialmente).
• Cipher suite negociada (AEAD moderna).
• Cadeia completa e verificação OK.
• Extensões como ALPN (se esperado).

Passo 7: monitorar em produção

TLS não é “configurar e esquecer”. Monitore:

• Taxa de erros de handshake (por versão, por motivo).
• Distribuição de versões negociadas (quanto ainda usa TLS 1.2).
• Expiração de certificados (alertas com antecedência).
• Falhas de OCSP stapling (se habilitado).

Downgrade, interceptação e proxies: riscos e controles

Em redes corporativas, proxies TLS (interceptação) podem reemitir certificados e “quebrar” expectativas de validação. Em ambientes internos isso pode ser intencional; em ambientes externos, pode ser um ataque. Controles práticos:

• Em clientes críticos, use pinning ou trust store restrita quando o ambiente permitir.
• Evite fallback inseguro (por exemplo, tentar HTTP após falha de TLS).
• Registre e alerte sobre mudanças inesperadas de cadeia/certificado em endpoints sensíveis.

Downgrade também pode ocorrer quando o servidor aceita versões antigas. Por isso, desabilitar TLS 1.0/1.1 e restringir suites em TLS 1.2 é uma defesa direta.

Erros comuns e como diagnosticar rapidamente

“Funciona no meu navegador, falha no meu serviço”

• Possível causa: cliente não envia SNI e recebe certificado errado. Solução: garantir SNI no cliente ou usar IP dedicado/cert padrão apropriado.
• Possível causa: cadeia intermediária faltando. Solução: instalar fullchain.
• Possível causa: cliente não suporta TLS 1.3 e servidor só habilitou 1.3. Solução: habilitar TLS 1.2 restrito.

Handshake falha após endurecimento

• Possível causa: você removeu suites necessárias para um cliente legado. Solução: decidir se vale suportar; se sim, isolar em endpoint/proxy separado.
• Possível causa: curva/grupo não suportado pelo cliente. Solução: manter P-256 como fallback comum.

mTLS “autentica”, mas autorização está errada

• Possível causa: qualquer certificado emitido por uma CA interna está sendo aceito como “acesso total”. Solução: mapear identidade do certificado para permissões explícitas (por SAN/URI, subject, políticas) e aplicar autorização no app/gateway.

Boas práticas resumidas para um baseline moderno

• Servidor: habilite apenas TLS 1.2 e 1.3.
• TLS 1.2: apenas ECDHE + AES-GCM/ChaCha20-Poly1305; sem RSA key exchange; sem CBC.
• TLS 1.3: suites padrão modernas (AES-GCM e ChaCha20-Poly1305).
• Grupos: X25519 e P-256 como base.
• Certificados: SAN correto, fullchain, renovação automatizada, monitoramento de expiração.
• Cliente: validação padrão + hostname obrigatório; sem “insecure skip verify”.
• Teste e monitore: scanners, openssl s_client, métricas de handshake e alertas.