O que é TLS mútuo (mTLS), e como ele funciona?

O que é TLS mútuo?

Num handshake comum, o cliente permanece anônimo na camada TLS. Ele verifica o certificado do servidor, mas o servidor não tem ideia de quem está se conectando até a própria aplicação pedir uma senha, uma chave de API ou um cookie de sessão, depois que a conexão criptografada já está de pé. O TLS mútuo move essa checagem de identidade para dentro do próprio handshake: o servidor pede um certificado ao cliente, o cliente apresenta um, e o servidor o verifica do mesmo jeito que um navegador verifica o certificado de um site, contra uma autoridade certificadora confiável e uma assinatura de chave privada correspondente.

Nada na criptografia muda. A mesma troca de chaves, os mesmos conjuntos de cifra, a mesma checagem Finished, tudo continua acontecendo. O mTLS só adiciona uma checagem de identidade extra rodando na outra direção, então uma conexão pode ser rejeitada por um certificado de cliente ruim antes mesmo de os dois lados trocarem um único byte de dado de aplicação.

Como um certificado de cliente muda o handshake?

No TLS 1.3 (RFC 8446), o servidor sinaliza que quer um certificado de cliente com uma mensagem CertificateRequest, enviada na Seção 4.3.2 logo depois do seu próprio Certificate e CertificateVerify. Essa mensagem carrega um certificate_request_context, descrito na RFC como "uma string opaca que identifica a requisição de certificado e que será ecoada na mensagem Certificate do cliente", além de extensões nomeando quais algoritmos de assinatura e quais autoridades certificadoras o servidor aceita.

O cliente responde com sua própria mensagem Certificate e seu próprio CertificateVerify, uma assinatura sobre a transcrição do handshake feita com a sua chave privada, a mesma estrutura que o servidor usou para se provar antes. A RFC 8446 Seção 4.4.2 é explícita que as duas direções são opcionais no nível de protocolo: a mensagem Certificate "é omitida pelo servidor se ele não estiver se autenticando com um certificado, e pelo cliente se o servidor não enviou CertificateRequest". Um detalhe é diferente do TLS 1.2: no TLS 1.3 essa troca inteira acontece depois do ServerHello, dentro da parte já criptografada do handshake, então o certificado de um cliente nunca viaja em texto simples do jeito que viajava no TLS 1.2, onde o CertificateRequest e o Certificate do cliente eram enviados antes de a criptografia começar.

Se o cliente não envia certificado nenhum quando um era exigido, ou envia um em que o servidor não confia, o servidor encerra o handshake. Nenhuma requisição de camada de aplicação chega a rodar.

Onde o mTLS é usado de verdade?

• Tráfego de serviço para serviço dentro de um data center ou de um service mesh. Quando toda chamada é entre serviços que a própria organização controla, os dois lados podem ter um certificado emitido por uma autoridade certificadora interna, e o mTLS vira a camada de controle de acesso entre eles, não só a camada de criptografia.
• Frotas de dispositivos IoT. Um dispositivo com um certificado gravado desde a fabricação consegue se autenticar num backend sem nunca lidar com usuário e senha, o que importa para hardware que não tem teclado nem um usuário sentado na frente para fazer login.
• Algumas APIs bancárias e de pagamento. Integrações no estilo open banking, em que uma aplicação de terceiros chama a API de um banco em nome de um cliente, costumam exigir que a aplicação que chama apresente o seu próprio certificado como parte da prova de que é a integração registrada e aprovada, e não um impostor com uma chave de API roubada.
• Redes internas Zero Trust. Onde o modelo de segurança assume que nenhum segmento de rede é confiável por padrão, o mTLS deixa cada conexão interna carregar a sua própria prova de identidade em vez de depender da localização na rede (estar "dentro do firewall") como substituto de confiança.

Quanto custa operar o mTLS?

O custo do próprio handshake é pequeno, um certificado a mais e uma verificação de assinatura a mais. O custo operacional é onde o mTLS fica caro, e é o motivo de ele ficar sobretudo em cenários de serviço para serviço e de frotas fechadas, em vez de aparecer em sites públicos voltados ao consumidor final:

• Distribuição de certificado. Todo cliente que precisa se autenticar precisa do seu próprio certificado e chave privada, emitidos por uma autoridade certificadora em que o servidor confia, entregues a esse cliente de forma segura antes mesmo da sua primeira conexão.
• Rotação e expiração. Certificados de cliente expiram do mesmo jeito que certificados de servidor, e uma frota de milhares de dispositivos ou serviços precisa de um processo de renovação que funcione, ou as conexões começam a falhar no dia em que os certificados vencem, o mesmo modo de falha que um handshake normal tem, só que multiplicado por cada cliente em vez de só pelo servidor.
• Revogação. Se a chave privada de um cliente é comprometida, o servidor precisa de um jeito de rejeitar aquele certificado específico antes da sua data de expiração, o que significa manter e checar uma lista de revogação ou um respondedor OCSP em toda tentativa de conexão.
• Armazenamento da chave privada no cliente. A chave privada do cliente precisa ficar guardada num lugar de onde não pode ser extraída facilmente, o que é simples num servidor e bem mais difícil num dispositivo móvel, num navegador, ou num hardware sem um enclave seguro.

Nada disso é impossível de operar, mas é uma operação de PKI de verdade, com autoridade certificadora própria, fluxo de emissão e processo de revogação, não uma mudança de configuração de uma linha só.

Como o mTLS é diferente de uma chave de API ou um bearer token?

Uma chave de API ou um bearer token é uma string secreta compartilhada, enviada dentro da própria requisição, tipicamente num header, depois que a conexão TLS já está estabelecida. Qualquer um que obtenha essa string, de um arquivo de log, de um proxy mal configurado ou de um cliente comprometido, pode reproduzi-la de qualquer lugar até que seja revogada ou expire. O servidor não tem como distinguir um portador legítimo do token de alguém que só copiou a string.

Um certificado de cliente prova a posse de uma chave privada como parte do próprio handshake, por meio da assinatura CertificateVerify, em vez de provar o conhecimento de uma string que viaja junto com cada requisição. A chave privada em si nunca atravessa a rede; só assinaturas feitas com ela atravessam. Essa é uma garantia mais forte contra uma credencial vazada sendo reutilizada, mas vem com a carga de PKI descrita acima, e não se encaixa em toda arquitetura: muitas CDNs, load balancers e proxies reversos encerram o TLS eles mesmos e abrem uma conexão nova até a origem, o que quebra a cadeia de confiança do certificado de cliente a menos que cada salto no meio do caminho seja construído deliberadamente para repassá-lo. Um bearer token, sendo um valor de camada de aplicação, sobrevive a um proxy que encerra o TLS sem nenhum tratamento especial.

Na prática, os dois costumam ser combinados em vez de tratados como uma escolha: o mTLS autentica a própria conexão, e um token ou uma credencial com escopo ainda cuida da autorização por requisição em cima disso. Checar se o handshake de um endpoint autenticado por certificado ainda funciona, do mesmo jeito que a ferramenta de verificação SSL/TLS verifica a cadeia de certificado num servidor comum, pega um certificado de cliente expirando ou mal configurado antes que ele comece a derrubar todo serviço que depende dele. O HostTracker monitora sites desde 2004, verifica a partir de mais de 300 pontos de verificação em 158 cidades, e pode avisar por e-mail, SMS, chamada de voz, Slack, Telegram e outros no momento em que uma verificação de certificado encontra um handshake que falha.

Perguntas frequentes

O mTLS substitui senhas e chaves de API por completo?

Normalmente não. O mTLS autentica a conexão; a maioria dos sistemas ainda coloca uma credencial ou um escopo de autorização em nível de aplicação por cima, já que um certificado prova qual serviço ou dispositivo está se conectando, não necessariamente o que esse chamador tem permissão de fazer depois de conectado.

Um navegador consegue usar TLS mútuo?

Sim, embora seja incomum fora de ambientes corporativos. Um navegador pode ser configurado para apresentar um certificado de cliente, e o sistema operacional ou o navegador vai perguntar qual escolher se um servidor pedir um, mas o problema da distribuição de certificado torna isso raro para qualquer coisa voltada ao consumidor final.

mTLS é a mesma coisa que uma VPN?

Não. Uma VPN cria um túnel de rede privado por onde qualquer tipo de tráfego pode passar. O mTLS é um método de autenticação para uma única conexão TLS, e não roteia nem tuneliza tráfego nenhum por conta própria; os dois às vezes são combinados, mas resolvem problemas diferentes.

O que acontece se um certificado de cliente expira sem ninguém notar?

Toda conexão que exige esse certificado começa a falhar o handshake na etapa de Certificate ou CertificateVerify, do mesmo jeito que um certificado de servidor expirado falha, só que a falha atinge todo serviço ou dispositivo dependente de uma vez, em vez de atingir cada visitante de um único site.

O mTLS deixa a conexão mais lenta?

O custo extra é um certificado a mais e uma verificação de assinatura a mais durante o handshake, o que é pequeno perto de um round trip típico. Isso não soma um round trip extra de rede no TLS 1.3, já que a troca do certificado de cliente viaja dentro do mesmo envio criptografado do resto do handshake.