SSL Pinning

O SSL Pinning é um mecanismo de segurança em que um aplicativo cliente fixa ("pins") de forma codificada o certificado criptográfico ou a chave pública esperada de um servidor, fazendo com que as conexões falhem quando um proxy tenta interceptar o tráfego com um certificado diferente, ainda que válido. Esse processo aumenta a segurança ao impedir ataques Man-in-the-Middle (MITM) que dependem de apresentar um certificado confiável, porém inesperado.

Como o SSL Pinning funciona

O SSL Pinning opera no lado do cliente, estendendo o processo padrão de validação do handshake TLS. Normalmente, durante um handshake TLS, o cliente verifica o certificado do servidor contra sua trust store (uma coleção de Autoridades Certificadoras raiz confiáveis). Se uma CA na trust store tiver assinado o certificado do servidor, a conexão prossegue.

Com o SSL Pinning, o aplicativo cliente armazena um identificador específico — seja o certificado completo, seja sua chave pública — para o servidor esperado. Quando uma conexão é iniciada:
1. O servidor apresenta seu certificado.
2. O cliente executa a validação padrão da cadeia de confiança usando sua trust store de CAs.
3. Adicionalmente, o cliente compara o certificado ou a chave pública apresentados pelo servidor com seu valor pré-fixado (pinned).
4. Se ambas as validações passarem (CA confiável e valor fixado correspondente), a conexão prossegue.
5. Se o valor fixado não corresponder, mesmo que o certificado seja assinado por uma CA confiável, a conexão é imediatamente encerrada com um erro de validação.

Essa verificação adicional torna significativamente mais difícil para um atacante, mesmo um que tenha comprometido uma CA confiável, interceptar o tráfego.

Tipos de SSL Pinning

Existem dois tipos principais de SSL Pinning:

• Certificate Pinning: o cliente fixa o certificado X.509 exato do servidor. Esse método é altamente específico, mas exige atualizar o aplicativo sempre que o certificado do servidor for renovado ou alterado.
• Public Key Pinning: o cliente fixa a chave pública extraída do certificado do servidor. Isso oferece mais flexibilidade do que o certificate pinning, pois a chave pública em geral permanece constante mesmo quando o certificado é renovado (desde que o par de chaves não mude). Isso costuma ser implementado fixando o hash do Subject Public Key Info (SPKI).

Exemplo: pinning conceitual no Android (Java)

import okhttp3.CertificatePinner;
import okhttp3.OkHttpClient;
import okhttp3.Request;

public class PinnedHttpClient {

    public static void main(String[] args) throws Exception {
        // Exemplo de hash SHA256 de uma chave publica.
        // Em uma aplicacao real, isso seria derivado do certificado do servidor alvo.
        String hostname = "api.example.com";
        String sha256_publicKey_hash = "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="; // Substitua pelo hash real

        CertificatePinner certificatePinner = new CertificatePinner.Builder()
                .add(hostname, sha256_publicKey_hash)
                .build();

        OkHttpClient client = new OkHttpClient.Builder()
                .certificatePinner(certificatePinner)
                .build();

        Request request = new Request.Builder()
                .url("https://" + hostname + "/data")
                .build();

        // Esta chamada falhara se a chave publica do servidor nao corresponder ao hash fixado,
        // mesmo que o certificado seja assinado por uma CA confiavel.
        try {
            client.newCall(request).execute();
            System.out.println("Connection successful (or would be if executed)");
        } catch (javax.net.ssl.SSLPeerUnverifiedException e) {
            System.err.println("SSL Pinning failed: " + e.getMessage());
        }
    }
}

Por que os aplicativos usam SSL Pinning

Os aplicativos, em especial os móveis e de IoT, implementam SSL Pinning por várias razões críticas de segurança:

• Proteção contra Autoridades Certificadoras (CAs) fraudulentas: o TLS padrão depende da integridade de todas as CAs na trust store do cliente. Se uma CA for comprometida ou emitir um certificado fraudulento para um domínio, um atacante poderia usá-lo para realizar um ataque MITM. O SSL Pinning contorna essa vulnerabilidade ao confiar explicitamente apenas em um certificado ou chave pública específicos, independentemente de outras CAs confiáveis.
• Mitigação da manipulação da trust store: em dispositivos controlados pelo usuário, um usuário ou malware pode instalar certificados raiz adicionais na trust store do dispositivo. Embora isso muitas vezes seja feito para depuração legítima, também pode ser explorado. O SSL Pinning garante que, mesmo que uma CA raiz maliciosa seja adicionada, o aplicativo ainda rejeitará conexões aos seus domínios fixados se o certificado apresentado não corresponder ao pin.
• Segurança reforçada para dados sensíveis: aplicativos que lidam com dados altamente sensíveis (ex.: bancos, saúde, tokens de autenticação) usam pinning para estabelecer um grau mais alto de confiança e reduzir a superfície de ataque para interceptação de rede.

Como o SSL Pinning afeta os proxies

Proxies, especialmente os projetados para inspeção de tráfego, depuração ou varredura de segurança, operam atuando como um intermediário (um MITM legítimo).

Quando um aplicativo usa um proxy para uma conexão HTTPS:
1. O cliente se conecta ao proxy.
2. O proxy estabelece sua própria conexão com o servidor alvo.
3. O proxy então gera, na hora, um novo certificado para o servidor alvo, assinado por sua própria CA raiz (que precisa ser confiável para o cliente para que o proxy funcione).
4. O proxy apresenta esse certificado recém-gerado ao cliente.

Esse processo é fundamentalmente incompatível com o SSL Pinning. O aplicativo cliente espera o certificado ou a chave pública do servidor original. Quando o proxy apresenta seu próprio certificado gerado, mesmo que seja assinado por uma CA confiável para o sistema operacional, o mecanismo de SSL Pinning do cliente detectará uma incompatibilidade com seu pin codificado. Como consequência, o cliente encerrará a conexão com um SSLPeerUnverifiedException ou erro semelhante, impedindo o proxy de interceptar e inspecionar o tráfego.

• Proxies transparentes: esses proxies interceptam o tráfego sem configuração explícita do cliente. Se o aplicativo cliente tiver o SSL Pinning habilitado, ele ainda detectará o certificado do proxy e encerrará a conexão, mesmo que o SO confie na CA raiz do proxy.
• Proxies de interceptação (explícitos): quando um cliente é configurado explicitamente para usar um proxy, o certificado do proxy ainda entrará em conflito com o certificado fixado do aplicativo, levando a falhas de conexão.

Impacto nas operações

• Depuração e desenvolvimento: desenvolvedores costumam usar proxies (ex.: Burp Suite, Fiddler, Charles Proxy) para inspecionar o tráfego de rede em depuração, desenvolvimento de API e análise de desempenho. O SSL Pinning obstrui isso diretamente, tornando impossível ver as requisições e respostas de rede do aplicativo.
• Testes de segurança: testadores de penetração dependem de proxies para analisar vulnerabilidades da aplicação, incluindo uso indevido de API, vazamento de dados e falhas de autenticação. O SSL Pinning impede que essas ferramentas funcionem corretamente, prejudicando avaliações de segurança abrangentes.
• Monitoramento e analytics: alguns ambientes corporativos usam proxies para monitoramento de rede, prevenção de perda de dados (DLP) ou analytics. Aplicativos com SSL Pinning contornam ou bloqueiam esses recursos de monitoramento.

Contornando o SSL Pinning (para fins legítimos)

Contornar o SSL Pinning geralmente é feito para fins legítimos, como testes de segurança, depuração ou engenharia reversa, e normalmente é realizado em ambientes controlados. Isso exige modificação do aplicativo cliente ou de seu ambiente de execução.

• Modificando o código do aplicativo: se o código-fonte estiver disponível, desenvolvedores podem remover ou desativar a lógica de pinning em builds de teste. Este é o método mais confiável.
• Frameworks de instrumentação em tempo de execução: ferramentas como Frida ou Xposed permitem modificar dinamicamente o comportamento do aplicativo em tempo de execução. Esses frameworks conseguem interceptar as chamadas da biblioteca SSL/TLS do aplicativo e contornar as verificações de pinning. Isso costuma exigir um dispositivo com root ou jailbreak.
  ```javascript
  // Exemplo de trecho de script Frida para contornar o SSL Pinning no Android (conceitual)
  Java.perform(function () {
  var CertificateFactory = Java.use("java.security.cert.CertificateFactory");
  var FileInputStream = Java.use("java.io.FileInputStream");
  var BufferedInputStream = Java.use("java.io.BufferedInputStream");
  var X509Certificate = Java.use("java.security.cert.X509Certificate");
  var KeyStore = Java.use("java.security.KeyStore");
  var TrustManagerFactory = Java.use("javax.net.ssl.TrustManagerFactory");
  var SSLContext = Java.use("javax.net.ssl.SSLContext");

  // TrustManagerImpl.checkTrustedRecursive costuma ser o alvo
  var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl');
  TrustManagerImpl.checkTrustedRecursive.implementation = function (a, b, c, d, e, f) {
      // Ignora a verificacao real, confiando efetivamente em todos os certificados
      return Java.array('java.security.cert.X509Certificate', []);
  };
  
  // ... outros hooks para varias bibliotecas SSL (OkHttp, Apache, etc.)
  

  });
  ```
  * Modificando os binários do aplicativo: para aplicativos cujo código-fonte não esteja disponível, ferramentas de engenharia reversa podem ser usadas para aplicar patch no binário compilado e desativar o pinning. Isso é complexo e exige considerável expertise.
  * Configuração do cliente com suporte a proxy: alguns aplicativos podem oferecer opções de configuração para confiar em CAs personalizadas ou desativar o pinning em modos de desenvolvimento, embora isso seja raro em aplicativos de produção.

Contornar o SSL Pinning deve ser feito de forma responsável e ética, principalmente para pesquisa de segurança, desenvolvimento ou testes autorizados. Contornar sem autorização, para fins maliciosos, é ilegal e antiético.