Fixação de Certificados em Aplicações Móveis e de Desktop

O TLS padrão confia em qualquer certificado assinado por qualquer uma das aproximadamente 150 CAs raiz pré-instaladas no sistema operacional. Se qualquer CA raiz for comprometida ou coagida, um invasor poderá obter um certificado para qualquer domínio e interceptar o tráfego TLS. A fixação de certificados restringe a confiança a um certificado ou chave pública específico, independentemente de qual CA o assinou. Um aplicativo com fixação rejeita conexões com seus servidores, a menos que o servidor apresente exatamente o certificado ou a chave esperados. Essa proteção é particularmente valiosa para aplicativos móveis, nos quais os usuários não podem inspecionar o tráfego de rede e as soluções corporativas de MDM podem instalar raízes de CA empresariais.

Há três níveis de granularidade na fixação: (1) Fixação do certificado completo — o certificado exato codificado em DER deve corresponder. Esta é a opção mais frágil: qualquer renovação do certificado causa uma falha. (2) Fixação da chave pública — somente os bytes de SubjectPublicKeyInfo (SPKI) são comparados. Ela sobrevive à renovação do certificado se o mesmo par de chaves for mantido. (3) Resumo de SPKI — armazene SHA-256(SPKI) em vez da chave bruta. Essa é a abordagem de HTTP Public Key Pinning (HPKP) e da Configuração de segurança de rede do Android. A fixação de chave pública ou SPKI é preferível: ela sobrevive à rotação da CA e à renovação do certificado, mas ainda detecta MITM com um par de chaves diferente.

O Android (API 24+) fornece um mecanismo declarativo de fixação por meio do XML de Configuração de segurança de rede. O arquivo res/xml/network_security_config.xml especifica fixações por domínio: pin-set com digest="SHA-256" e o resumo SPKI codificado em base64. O aplicativo referencia esse arquivo em AndroidManifest.xml por meio de android:networkSecurityConfig. O Android aplica as fixações a todas as conexões HTTP feitas por meio de HttpsURLConnection e OkHttp padrão (ao usar o gerenciador de confiança da plataforma). O pin-set exige pelo menos uma fixação de backup (uma chave ou fixação de CA diferente) para evitar o bloqueio se a chave principal for comprometida. A expiração da fixação (atributo expiration) força os aplicativos a serem atualizados antes que as fixações fiquem obsoletas.

Os aplicativos iOS implementam a fixação em delegados de NSURLSession. O método delegado URLSession(_:didReceive:completionHandler:) recebe o objeto de confiança do servidor. O aplicativo chama SecTrustEvaluateWithError para validar a cadeia, depois extrai o certificado folha com SecTrustGetCertificateAtIndex(trust, 0), exporta seus bytes SPKI, calcula seu resumo SHA-256 e compara o resultado com a fixação armazenada. O TrustKit (biblioteca de código aberto) encapsula esse padrão com fixação baseada em configuração, oferecendo várias fixações, correspondência de subdomínios e modo somente para relatório. O App Transport Security (ATS) da Apple é separado da fixação — o ATS impõe versões mínimas do TLS, mas não fixa chaves.

A fixação de chave pública HTTP (HPKP, RFC 7469) tentou adicionar fixação aos navegadores por meio de cabeçalhos de resposta HTTP: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. O navegador lembraria da fixação durante o período de max-age e rejeitaria conexões com chaves incompatíveis. O HPKP foi descontinuado pelo Chrome em 2017 e removido em 2019 devido a falhas catastróficas: uma única configuração incorreta ou perda de chave poderia bloquear permanentemente os usuários de um site, sem possibilidade de recuperação. O HPKP agora está efetivamente extinto nos navegadores; a fixação no nível do aplicativo em aplicativos móveis continua viável porque as atualizações do aplicativo podem incluir novas fixações.

O OkHttp (amplamente usado no Android) oferece suporte à fixação por meio de CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). A segunda fixação é a cópia de segurança. O OkHttp verifica se pelo menos uma fixação corresponde a qualquer certificado na cadeia do servidor — folha, intermediário ou raiz. Isso permite fixar uma CA intermediária (sobrevivendo à rotação do certificado folha) ou fixar a CA raiz (sobrevivendo à rotação do intermediário). O OkHttp lança uma SSLPeerUnverifiedException com uma mensagem útil que lista os resumos SPKI reais do servidor, tornando simples extrair a fixação durante o desenvolvimento.

A fixação dificulta a interceptação do tráfego, mas não é inquebrável. Técnicas comuns de contorno em dispositivos móveis: (1) Ganchos do Frida — injetam JavaScript no processo do aplicativo para interceptar o método de verificação da fixação e retornar true incondicionalmente. (2) Ferramentas SSLUnpinning — scripts automatizados de Frida/Objection direcionados a bibliotecas comuns de fixação (TrustKit, OkHttp, SecTrust nativo). (3) ROM personalizada — obter acesso root ao dispositivo e modificar a pilha TLS. (4) Reempacotamento — descompilar o APK, modificar a configuração de fixação e reempacotar com um novo certificado. (5) Alteração da memória — alterar o bytecode de verificação durante a execução. Mitigações: detecção de root/jailbreak, ofuscação de código e verificações de integridade (SafetyNet/App Attest).

O maior risco operacional da fixação de certificados é o bloqueio causado pelo próprio aplicativo: se a chave de produção for perdida ou o certificado expirar e a cópia de segurança estiver indisponível, os usuários ficarão bloqueados até que uma atualização do aplicativo seja distribuída (dias ou semanas). Práticas recomendadas: (1) Fixe sempre pelo menos duas chaves — a chave atual e uma chave de cópia de segurança pré-gerada, armazenada offline (em HSM ou em um ambiente isolado da rede). (2) Defina uma data de expiração da fixação e distribua atualizações antes da expiração. (3) Monitore as falhas de fixação no modo somente para relatório antes de aplicar a política. (4) Mantenha um fluxo de atualização emergencial do aplicativo (análise acelerada) para incidentes de rotação de fixações. (5) Faça a fixação no nível da CA intermediária, não no certificado folha, para permitir a rotação do certificado folha sem atualizações do aplicativo.

Aplicativos para computador escritos em Electron, Qt ou código nativo podem implementar a fixação usando as APIs de sua pilha TLS. Aplicativos Electron usam o evento app.on("certificate-error") e session.setCertificateVerifyProc() para implementar a verificação personalizada. O código de rede do Qt usa QSslSocket com uma função de retorno de chamada de verificação personalizada. Aplicativos .NET usam ServicePointManager.ServerCertificateValidationCallback. Aplicativos nativos do Windows usam WinHTTP com inspeção manual de certificados. Os aplicativos para computador enfrentam desafios adicionais: a interceptação TLS no nível do sistema operacional por proxies corporativos é comum, e os usuários podem esperar que a funcionalidade de proxy funcione — o que exige uma decisão de política sobre se a fixação se aplica somente a pontos de extremidade específicos.

A fixação de certificados complica os testes automatizados e os fluxos de CI/CD. Os testes de integração que fazem chamadas HTTPS reais a servidores de preparação devem usar certificados de teste cujos resumos SPKI estejam fixados em uma configuração de teste. Abordagens: (1) Variantes de compilação — a compilação de depuração ou preparação inclui as fixações do servidor de preparação; a compilação de lançamento fixa a produção. (2) Substituições da Configuração de segurança de rede — o Android permite uma configuração de fixação exclusiva para depuração. (3) Servidor simulado — interceptar no nível do cliente HTTP antes do TLS, ignorando completamente a fixação. (4) CA autoassinada para CI — emitir certificados de teste a partir de uma CA de CI cuja raiz seja confiável somente nas compilações de teste. Nunca distribua uma compilação com a fixação desabilitada em produção.

As fixações de certificados geralmente são resumos de chaves públicas RSA ou EC. Quando a migração pós-quântica começar, os servidores passarão para ML-DSA (CRYSTALS-Dilithium) ou chaves híbridas. Os resumos SPKI fixados mudarão porque o tipo e a codificação da chave serão alterados. Os aplicativos que fixam certificados folha ou chaves públicas precisarão de atualizações coordenadas: (1) Distribuir uma nova versão do aplicativo com o resumo SPKI pós-quântico como fixação de cópia de segurança antes da migração do servidor. (2) Concluir a migração do servidor. (3) Distribuir uma atualização removendo a antiga fixação clássica. A janela de transição exige coordenação cuidadosa. Os aplicativos que fixam CAs intermediárias ou raiz serão menos afetados — somente a chave da CA muda, não necessariamente no mesmo cronograma dos certificados folha.

Por que a fixação do hash de SubjectPublicKeyInfo (SPKI) é preferível à fixação do certificado completo?

A fixação de certificados restringe a confiança do TLS a um certificado ou chave pública específico, protegendo contra o comprometimento de uma CA e ataques MITM. A fixação pelo hash de SPKI (SHA-256 de SubjectPublicKeyInfo) é preferível à fixação do certificado completo por ser resiliente à renovação. O Android usa o XML de configuração de segurança de rede; o iOS usa um delegado de URLSession com APIs SecTrust; OkHttp oferece suporte a CertificatePinner. Inclua sempre uma fixação reserva para evitar o bloqueio do próprio aplicativo. HPKP (um cabeçalho HTTP do navegador) foi descontinuado. A fixação pode ser contornada por interceptações do Frida e modificações da ROM. A migração para chaves pós-quânticas exige atualizações coordenadas do aplicativo para atualizar os hashes de SPKI.