TLS vs mTLS | Diferenças e quando usar cada um

O TLS é o “cadeado” padrão da web: ele criptografa o tráfego e autentica o servidor. No entanto, em um mundo de APIs B2B, microserviços e IoT, saber quem está chamando sua aplicação é tão crítico quanto proteger os dados em trânsito. O problema? O TLS padrão não autentica o cliente.

É aqui que entra o mTLS (Mutual TLS). Ele mantém a criptografia robusta do TLS, mas exige que o cliente também apresente um certificado digital e prove a posse de uma chave privada. Neste guia, exploramos por que o mTLS é o alicerce do Zero Trust e como implementá-lo com performance no Edge.

Key Takeaways (Resumo Prático)

• TLS Padrão: O cliente confia no servidor. Ideal para a web pública.
• mTLS: Cliente e servidor confiam um no outro. Essencial para comunicações machine-to-machine.
• Handshake TLS 1.3: Mais rápido e privado, criptografando os certificados para evitar vazamento de metadados.
• Edge Advantage: Encerrar o mTLS na borda evita sobrecarga (CPU exhaustion) na sua origem.

O que é TLS (Standard) — e quais são seus limites

No TLS padrão (ou one-way TLS), o servidor apresenta um certificado X.509 e o cliente verifica a validade, a cadeia de confiança e o nome do host.

• cadeia de confiança até uma CA confiável
• validade (notBefore / notAfter)
• nome do host (SAN/CN) compatível com o domínio acessado
• revogação (quando habilitada, via OCSP/CRL)

Com isso, você obtém:

• confidencialidade (tráfego criptografado)
• integridade (proteção contra alteração)
• autenticação do servidor (cliente confirma com quem está falando)

O que o TLS padrão não resolve por conta própria: autenticação do cliente.
O servidor sabe que o canal é seguro, mas ainda depende de métodos de aplicação (API Keys, JWT, OAuth2) para saber quem é o usuário ou serviço do outro lado.

O que é mTLS (Mutual TLS)

O mTLS (Mutual TLS) é uma extensão do modelo: cliente e servidor apresentam certificados e se validam mutuamente. O cliente não apenas “mostra uma credencial”; ele precisa realizar uma assinatura criptográfica durante o handshake para provar que possui a chave privada correspondente ao certificado apresentado. Isso impede que um atacante copie o certificado e tente reutilizá-lo em outro lugar.

O mTLS estende o modelo de confiança: ambas as partes se validam. No fluxo mTLS, não basta o cliente “mostrar uma credencial”; ele precisa realizar uma assinatura criptográfica durante o handshake para provar que possui a chave privada correspondente ao certificado apresentado.

Na prática:

1. o cliente valida o certificado do servidor (como no TLS padrão);
2. o servidor solicita um certificado do cliente;
3. o cliente apresenta seu certificado;
4. o cliente prova posse da chave privada (ponto crucial).

Essa prova de posse é o que faz mTLS ser tão atrativo em ambientes Zero Trust, integrações B2B e comunicação entre serviços: não basta “ter uma credencial”; é necessário assinar o handshake.

mTLS vs TLS: Principais Diferenças

Handshake TLS 1.3: Passo a Passo com mTLS

O TLS 1.3 trouxe uma evolução massiva em privacidade. Enquanto no TLS 1.2 os certificados eram enviados em texto claro (permitindo que um observador na rede soubesse qual serviço estava se conectando), no 1.3 eles são criptografados logo após o primeiro contato.

O Fluxo Detalhado

1. ClientHello: O cliente inicia enviando versões e parâmetros de troca de chaves.
2. ServerHello: O servidor fecha os parâmetros e, a partir daqui, a comunicação é criptografada.
3. EncryptedExtensions: Extensões de protocolo são enviadas de forma protegida.
4. CertificateRequest (Gatilho mTLS): O servidor solicita formalmente o certificado do cliente.
5. Certificate (Servidor): O servidor envia sua identidade (agora criptografada para observadores externos).
6. CertificateVerify (Servidor): O servidor assina o handshake, provando que é dono da chave privada.
7. Certificate (Cliente): O cliente responde com seu certificado.
8. CertificateVerify (Essência do mTLS): O cliente assina o transcript do handshake. Isso impede que um atacante copie o certificado e tente reutilizá-lo em outro lugar.
9. Finished: Conexão estabelecida.

Pro Tip (Performance & 0-RTT): O TLS 1.3 permite o modo 0-RTT (Zero Round Trip Time) para reconexões ultra-rápidas. No entanto, ao usar mTLS com 0-RTT, certifique-se de que sua infraestrutura de borda (Edge) possua proteção contra ataques de replay, garantindo que requisições sensíveis (como transações financeiras) não sejam processadas duas vezes indevidamente.

mTLS vs API Keys e OAuth2

Por que mTLS vence as API Keys?

API Keys são fáceis de implementar, mas vulneráveis: elas vazam em logs, prints e repositórios. O mTLS exige a posse da chave privada, que pode estar protegida em hardware (HSM/TPM), tornando a exfiltração de credenciais muito mais complexa.

mTLS substitui o OAuth2?

Não, eles se complementam. O mTLS autentica a “máquina” (identidade do serviço), enquanto o OAuth2 governa a “autorização” (o que aquele serviço pode fazer). Arquiteturas maduras usam mTLS para o canal e OAuth2 para os escopos e delegações.

O mTLS muda o jogo porque o cliente não “mostra uma senha”; ele precisa provar a posse de uma chave privada durante o handshake. Quando as chaves ficam em hardware (TPM/HSM/secure element) ou são não extraíveis, você reduz muito o risco de exfiltração e reutilização.

Regra prática:

• API Key: protótipo/baixa criticidade (ou complemento)
• mTLS: identidade forte para B2B, microserviços, IoT e infra crítica

Onde faz sentido usar mTLS

mTLS é especialmente útil quando você precisa ter alta confiança na identidade do chamador:

• Microserviços / service-to-service: garantir que serviço A só fala com serviço B
• APIs B2B: parceiros e integrações com identidade forte
• IoT corporativo: autenticar dispositivos (sensores, gateways, câmeras) por certificado
• Ambientes regulados: open finance, saúde, telecom, governo
• Zero Trust: reduzir confiança implícita em redes internas

Em contrapartida, para web pública (navegador/usuário final), mTLS costuma ter desafios de UX e distribuição de certificados.

Exemplo Prático: Políticas de mTLS na Azion

Implementar mTLS na origem pode causar picos de latência e consumo de CPU. A estratégia recomendada é encerrar o mTLS no Edge. O Azion Firewall valida o certificado e injeta metadados (como o Fingerprint ou Subject DN) em headers seguros para que sua aplicação tome decisões.

Abaixo, um exemplo de Function para validar identidades específicas:

/**
 * Azion Function: mTLS Identity Enforcement
 * O Firewall deve estar configurado para encaminhar os metadados
 * do certificado nos headers (ex: X-Azion-Client-Cert-Subject)
 */

async function handleRequest(request) {
  const clientSubject = request.headers.get('x-azion-client-cert-subject');
  const clientFingerprint = request.headers.get('x-azion-client-cert-fp');

  // 1. Bloqueio se o certificado estiver ausente
  if (!clientSubject) {
    return new Response('Mutual TLS Authentication Required.', { status: 401 });
  }

  // 2. Validação de Identidade (CN - Common Name)
  // Exemplo: Permitir apenas o serviço de pagamentos da Acme
  if (!clientSubject.includes('CN=payments-service,O=Acme')) {
    return new Response('Forbidden: Service identity not authorized.', { status: 403 });
  }

  // 3. Verificação de Revogação (Denylist Instantânea)
  // Consulta uma denylist em cache no Edge para alta performance
  const isRevoked = await checkRevocation(clientFingerprint);
  if (isRevoked) {
    return new Response('Unauthorized: Certificate revoked.', { status: 401 });
  }

  // Identidade validada! Prossegue para o origin com header de confiança
  const headers = new Headers(request.headers);
  headers.set('X-Verified-Service', 'payments-v1');

  return fetch(request.url, new Request(request, { headers }));
}

Gestão de Certificados: O Calcanhar de Aquiles

O mTLS só é sustentável com automação. Em ambientes de larga escala, considere:

• Certificados de Curta Duração: Reduzem a necessidade de consultar CRLs/OCSP pesados.
• Rotação Automatizada: Use ferramentas que renovam certificados sem intervenção humana.
• Edge Denylist: Use o armazenamento de cache da Azion para manter listas de certificados revogados atualizadas globalmente em milissegundos.

CRL vs OCSP: visão prática

• CRL (Certificate Revocation List)

  • Prós: simples, dá para cachear
  • Contras: pode crescer; existe janela entre atualização e propagação

• OCSP (Online Certificate Status Protocol)

  • Prós: consulta pontual por certificado
  • Contras: depende do responder; pode adicionar latência se consultado toda hora

Estratégias que funcionam bem em produção

1. Short-lived certificates
   Diminui a necessidade de revogar “no susto”. Se um certificado expira rápido, a janela de risco cai.

2. Automação de rotação/renovação
   O objetivo é tornar renovar tão automático quanto renovar um certificado de servidor.

3. Denylist distribuída (serial/fingerprint)
   Para bloqueio imediato (ex.: incidente). É comum manter um endpoint/serviço de revogação consultado pela borda com cache/TTL.

Como mitigar revogação e reduzir latência na borda

Encerrar TLS/mTLS na borda ajuda porque você pode:

• concentrar validação de cadeia e políticas em um único ponto
• usar cache de verificações (CRL/OCSP/denylist)
• impedir tráfego inválido antes de alcançar a origem

Se seu origin está sofrendo com handshakes, picos de CPU ou políticas distribuídas em múltiplos serviços, avalie mover o enforcement de mTLS para a borda.

Troubleshooting: erros comuns de implementação

Abaixo, um checklist que resolve a maioria dos problemas em produção.

1) Cliente não apresenta certificado

Causas comuns

• mTLS não foi exigido (sem CertificateRequest)
• cliente não tem cert configurado (store vazio)
• policy/ciphers/versões incompatíveis

Como depurar

• habilitar logs no terminador TLS (Edge)
• testar com openssl s_client usando -cert e -key

2) “unknown ca” / falha de cadeia

Causas comuns

• CA do cliente não está no truststore do servidor/Edge
• cadeia incompleta (faltam intermediates)

Como corrigir

• adicionar CA raiz/intermediates corretos
• validar chain com ferramentas de inspeção X.509

3) Certificado expirado / not yet valid

Causas comuns

• rotação falhou
• clock skew (NTP) em ambientes restritos

Como corrigir

• sincronizar NTP
• automatizar renovação/rotacionar com antecedência

4) Revogação: cliente deveria estar bloqueado, mas ainda acessa

Causas comuns

• CRL/OCSP não está habilitado
• cache com TTL longo demais
• ausência de denylist imediata

Como corrigir

• habilitar verificação de revogação onde aplicável
• reduzir TTL e adicionar denylist por serial/fingerprint

FAQ (People Also Ask)

O mTLS reduz a velocidade da aplicação?

mTLS aumenta o custo do handshake (operações de chave pública), mas com TLS 1.3, resumption e término na borda (Edge), o impacto costuma ser pequeno. Além disso, tirar o custo da origem é uma das maiores vantagens operacionais.

Posso usar mTLS em navegadores comuns?

É possível, mas é difícil para usuário final: distribuição/instalação de certificados, UX ruim (prompts), e suporte variado em mobile. mTLS é mais adequado para B2B e comunicação entre serviços.

mTLS substitui OAuth2?

Não necessariamente. mTLS autentica o cliente (máquina/serviço) com alta confiança; OAuth2 governa autorização e escopos. Em muitas arquiteturas, eles se complementam.

O que fazer se um certificado de cliente for comprometido?

Revogar via CRL/OCSP (quando aplicável) e/ou bloquear imediatamente via denylist por serial/fingerprint. Quando possível, prefira certificados de curta duração com rotação automatizada para reduzir a janela de risco.

Conclusão

O mTLS não é apenas “mais um protocolo”; é a fundação da confiança mútua em sistemas distribuídos. Ao mover a verificação de certificados para o Edge, você ganha a segurança do Zero Trust sem o custo de performance da criptografia assimétrica na sua origem.

Pronto para implementar mTLS com baixa latência? Explore a documentação da Azion sobre Firewall ou fale com nossos especialistas para arquitetar sua segurança de APIs.