mitmproxy adiciona opção --emudhra
O mitmproxy adicionou uma opção `--emudhra` que aproveita chaves intermediárias da eMudhra recentemente expostas e trivialmente fracas — uma delas era literalmente o número 4 — para gerar certificados HTTPS que muitos dispositivos antigos ou não atualizados ainda confiam. Comentadores exploram como isso permite a interceptação transparente do tráfego de telefones Android legados, smart TVs e dispositivos IoT, ao mesmo tempo em que destacam a falha mais ampla na revogação de certificados e nas atualizações de trust store em plataformas como iOS e macOS. O incidente levanta questões sobre governança de CAs, possíveis backdoors, uso responsável de tais ferramentas e se a exposição pública de uma autoridade certificadora é justificada dada a gravidade da falha.
Novo recurso --emudhra no mitmproxy
- A opção assina certificados TLS interceptados com uma das chaves intermediárias eMudhra agora públicas.
- Destina-se a ser uma forma prática de testar quais dispositivos e apps ainda confiam nessas cadeias comprometidas.
- Alguns sugerem integrar múltiplas cadeias comprometidas (caminhos emSign e AAA) para cobertura mais ampla; um merge request está vinculado.
Casos de uso: depuração, engenharia reversa, jailbreak
- Respostas entusiasmadas sobre usar isto em:
- Telefones Android mais antigos (se os apps não fizerem pinning ou não usarem seu próprio trust store).
- Smart TVs e dispositivos IoT para observar tráfego do fornecedor, configurações ou atualizações de firmware.
- Fluxos mitm descritos: interceptar canais de configuração/firmware/anúncios que podem habilitar modos de desenvolvedor ou resultar em RCE.
- Limitações: pinning de certificado, attestation, roots privadas e dispositivos que já atualizaram ou revogaram a confiança.
Detalhes do comprometimento da eMudhra
- Oito CAs intermediárias tinham chaves privadas P-384 absurdamente fracas; foram dados exemplos (4, 56, 66, etc.), efetivamente 3–8 bits de entropia.
- Algumas explicações dizem que isso parece chaves de 8 bits usadas por engano onde 384 bits eram esperados.
- Roots envolvidas: emSign ECC Root CA – G3 e uma root AAA mais antiga; discutem-se cronogramas de quando cada uma está ou não em trust stores principais.
- Observa-se que a busca por chaves de curva elíptica exige cerca de esforço 2^(n/2), tornando chaves EC “moderadamente fracas” passíveis de brute force em GPUs.
Comportamento de revogação da plataforma (especialmente Apple)
- Vários usuários relatam resultados inconsistentes em iOS, iPadOS e macOS ao visitar sites de teste:
- Alguns veem todas as cadeias bloqueadas.
- Outros ainda veem 1–3 cadeias forjadas aceitas.
- Hipóteses incluem rollout em fases, falhas de consulta OCSP/CRL ou timeouts; o comportamento continua obscuro.
- A desconfiança manual das roots no Keychain do macOS bloqueia de forma confiável as cadeias ruins.
Ética, nomenclatura e temas mais amplos de segurança
- Visões mistas sobre nomear a opção
--emudhra:- Alguns veem isso como responsabilização justa por uma falha gravíssima de uma CA.
- Outros veem como perseguir pessoas que “nunca vão deixar isso passar”.
- Vários comentários enquadram isso como “transformar um desastre de segurança em uma ferramenta defensiva”, permitindo que usuários inspecionem e controlem dispositivos que fornecedores tentam trancar.
- São mencionadas propostas para varrer sistematicamente todas as CAs em busca de chaves igualmente fracas; uma resposta observa que esse problema específico foi encontrado usando ferramentas existentes e que nenhuma outra chave fraca foi observada nessa varredura.