O que o certificate pinning ainda bloqueia

No iOS, a descriptografia depende de o perfil do Busymate estar instalado e com confiança total nos Ajustes — depois disso, todo app do celular confia no certificado que o app apresenta, exceto os apps que fazem pinning. No Android há dois repositórios: o do usuário, que desde o Android 7.0 só é honrado por apps que optam explicitamente por ele, e o do sistema, que todo app honra mas no qual só um dispositivo com root pode escrever. O proxy de desktop usa a confiança que a máquina ou o navegador cliente tiver na autoridade gerada por ele.

O pinning fica acima dos três. Um app que faz pinning rejeita o certificado substituto de qualquer repositório que ele venha, então mover um certificado para um repositório mais forte nunca ajuda contra um host com pinning. Só ajuda contra apps que estavam recusando o repositório do usuário.

Um host que você não listou para descriptografia mostra um cadeado fechado com apenas o nome e uma contagem de requisições — isso é por design, não pinning. Um host com pinning parece diferente: ele está na sua lista, a descriptografia foi tentada, e a conexão falhou ou o app tentou de novo e desistiu. O filtro de inspeção do feed do dashboard tem três opções — só descriptografados, só criptografados e só com SSL pinning — e a última isola exatamente essas linhas.

O outro sinal é comportamental: o app para de funcionar para aquele host no momento em que ele é descriptografado, e volta a funcionar no momento em que você remove o host da lista. Se as duas coisas forem verdade, você encontrou uma conexão com pinning.

O app iOS captura o sistema inteiro, por Wi-Fi e rede celular, e descriptografa os hosts que você lista. Diante de um app com pinning ele ainda registra cada conexão — o host, o tempo, o número e o tamanho das requisições, o modo de conexão em vigor — mas não consegue produzir os cabeçalhos nem o corpo, e não há chave que mude isso. Ligar o MITM All Hosts descriptografa todos os hosts sem pinning; em um host com pinning, só serve para quebrá-lo.

O movimento prático é tirar o host com pinning da lista para o app continuar funcionando, manter os outros hosts do app nela e ler o que os endpoints sem pinning revelam. Muitos apps fazem pinning só no host de autenticação ou de pagamento e deixam o resto aberto.

Em um Android sem root, o certificado gerado pelo app fica no repositório do usuário, então só seus builds de debug e outros clientes que optaram por ele são descriptografados; todos os outros apps são registrados como metadados. Em um dispositivo com root, o certificado pode ser instalado no repositório do sistema, e o HTTPS passa a ser descriptografável em todo o sistema — exceto pelo pinning de cada app. A farm de celulares roda seus Androids nesse nível com root exatamente por isso.

Ou seja, o root converte uma classe de apps opacos em legíveis — os que apenas ignoravam o repositório do usuário — e deixa a classe com pinning intocada. O Busymate nunca afirma descriptografar todo o sistema em um dispositivo sem root, e nunca afirma derrotar o pinning em um com root.

O proxy de desktop tem a mesma relação com o pinning que os apps de celular: um cliente com pinning recusa o certificado gerado e a conexão falha. Ele também carrega uma lista curta de hosts que nunca intercepta, não importa o que suas configurações de SSL proxy digam — a PKI e os endpoints de revogação da Apple, os respondedores de status de certificado que a cadeia da Apple usa e o próprio backend do Busymate — porque interceptá-los quebraria o dispositivo ou a conexão ao vivo do dashboard. Eles passam como túneis brutos, e isso é intencional, não um erro de configuração.

Há um caminho de captura em que o pinning é irrelevante. O conector de linha de comando abre uma instância do Chrome e lê o tráfego dela pelo DevTools Protocol, do lado do navegador do TLS. A conexão criptografada entre o Chrome e o servidor nunca é tocada — não há certificado substituto para rejeitar, nada para instalar e nada para o pinning detectar. Fluxos de login em provedores cujos certificados fixados um proxy não consegue abrir são registrados de ponta a ponta, redirecionamentos e tokens inclusos.

O preço é o escopo: ele cobre o que roda dentro daquele Chrome, não um app nativo. Se o fluxo que importa para você tem versão web, esse é o caminho que o enxerga por inteiro.

Metadados não são nada desprezível. Você ainda vê quando o app fala com o host com pinning, com que frequência, o tamanho das trocas e quanto tempo elas levam, e pode correlacionar isso com as chamadas descriptografadas ao redor. Regras de bloqueio ainda casam no nível do host em um host criptografado — o caminho é invisível, mas você pode fazer o app se comportar como se aquele endpoint estivesse inacessível, que muitas vezes é exatamente o modo de falha que você queria testar. As pausas deixam o host contornar o proxy por completo para o app continuar funcionando enquanto você inspeciona todo o resto.

E toda ação que você fez está na trilha de auditoria, então uma sessão de pesquisa deixa registro do que foi descriptografado, do que foi bloqueado e do que foi deixado em paz.