Android 14 bloqueia até root de modificar certificados do sistema?
(httptoolkit.com)- O Android 14 (API v34) passou a ler certificados de CA do sistema não de
/system, mas do módulocom.android.conscryptbaseado em APEX, quebrando o fluxo de depuração existente que injetava certificados com privilégios de root - Desde o Android 7 Nougat, o repositório de confiança padrão dos apps foi dividido entre CAs do sistema e CAs do usuário, e ferramentas de desenvolvimento, teste e engenharia reversa vinham dependendo da modificação direta do diretório de CAs do sistema
- A nova estrutura permite atualizar certificados de CA por meio do Google Play System Update, tornando mais rápida a remoção de CAs problemáticas e a distribuição de novas CAs, mas reduz o controle do proprietário do dispositivo
- No emulador beta do Android 14, mesmo cobrindo ou removendo
/system/etc/security/cacerts,/system/etc/security/cacerts_google,/apex/com.android.conscrypt/cacertsetc. com tmpfs, as Configurações e os apps continuavam vendo a lista de CAs do Google - No momento da publicação, as alternativas realistas eram permanecer no Android 13 ou usar um sistema operacional customizado que não usasse APEX; depois, em atualizações, o autor informou que surgiram vários métodos de contornar a injeção de certificados no Android 14
Como a gestão de CAs no Android foi mudando
- Quando o Android foi anunciado pela Open Handset Alliance em 2007, ele enfatizava a abertura com expressões como “open platform” e “complete access to handset capabilities and tools”
- Com o tempo, avalia-se que o escopo no qual usuários, desenvolvedores e pesquisadores conseguem controlar seus próprios dispositivos foi ficando cada vez menor
-
A virada do Android 7 Nougat
- A lista de CAs que o proprietário do dispositivo podia modificar foi separada em CAs do sistema e CAs do usuário
- A lista fixa de CAs do sistema fornecida pelo fornecedor do SO passou a ser o padrão para todos os apps
- A lista de CAs modificável pelo usuário passou a ser usada apenas quando o app opta explicitamente por isso
- Como resultado, quase todos os apps deixaram de confiar, por padrão, nas CAs do usuário
Por que certificados de CA são importantes
- As CAs confiáveis do dispositivo são uma lista de organizações que garantem a segurança do tráfego de rede criptografado
- Uma CA pode emitir certificados usados em conexões TLS, como HTTPS, para domínios arbitrários, e dispositivos que confiam nessa CA aceitam esses certificados como prova de uma conexão legítima
- Se o usuário fizer o dispositivo confiar em uma CA criada por ele mesmo, poderá interceptar e inspecionar seu próprio tráfego HTTPS ou TLS
- É possível verificar os dados que o celular envia e recebe
- Se necessário, é possível modificá-los ou bloqueá-los
- Esse controle é importante para pesquisa em segurança e privacidade, engenharia reversa, depuração e teste de apps, configurações de redes corporativas internas e usuários que não confiam nas CAs padrão
- É razoável dificultar que usuários não técnicos alterem CAs por engano ou impedir que isso aconteça sem o conhecimento do usuário, mas restringir também o controle de usuários avançados dificulta vários casos de uso
A abordagem de contorno baseada em root após o Android 7
- Mesmo depois do Android 7, em dispositivos com root ainda era possível manipular diretamente o repositório de CAs do sistema
- A forma típica era colocar o certificado confiável em
/system/etc/security/cacerts/ - Mesmo em dispositivos com root,
/systemnormalmente é somente leitura, então eram usadas duas abordagens- Reconfigurar o diretório
/systemcomo gravável, reiniciar e então modificar o diretório real de certificados do sistema - Montar um sistema de arquivos temporário de leitura/gravação sobre o diretório somente leitura, copiar as CAs existentes e adicionar o novo certificado
- Reconfigurar o diretório
- Para que o certificado fosse aceito pelo sistema, também era necessário atender a condições como nome de arquivo, permissões e rótulo SELinux
- O HTTP Toolkit automatizava o procedimento baseado em montagem temporária e oferecia configuração de interceptação com um clique em dispositivos Android com root ou emuladores
- Essa abordagem funcionava em dispositivos customizados com root, distribuições Android especiais e na maioria das imagens oficiais de emulador do Google
- As imagens bloqueadas de edição completa “Google Play”, como em dispositivos OEM comuns, eram a exceção
- A documentação de configuração do mitmproxy, vários posts de blog, respostas no StackOverflow, posts em fóruns, pacotes Magisk e orientações do cacert.org usavam métodos parecidos
A nova estrutura de atualização de CAs do Android 14
- No momento em que o texto foi escrito, o Android 14 estava na fase beta final e deveria ser lançado em poucas semanas
- Um dos principais recursos de segurança são certificados de CA atualizáveis remotamente
- A gestão de certificados de CA foi separada da imagem central do SO e movida para um componente separado distribuído e atualizado pelo Google Play
- Com essa estrutura, o Google consegue revogar mais rapidamente a confiança em CAs problemáticas
- Reduz-se a necessidade de esperar que cada fabricante de celular distribua uma atualização OTA completa do SO
- Só com o Google Play System Update, é possível alterar a lista de CAs em dispositivos Android 14+
- As CAs confiáveis por padrão têm poderes fortes, então precisam de supervisão e sanções, e CAs que falhem devem ter seus privilégios removidos rapidamente
- Como exemplo, em janeiro de 2023 a TrustCor perdeu a confiança como CA de atores importantes, incluindo o Google, depois que foram descobertas relações próximas com organizações de distribuição de malware e contratadas de defesa e inteligência dos EUA
- O atraso na distribuição de novas CAs também causa problemas
- A Let’s Encrypt precisou adiar várias vezes a distribuição de melhorias na cadeia de assinatura porque dispositivos Android antigos não tinham a CA raiz mais recente
- A estrutura que aumenta a responsividade das atualizações de CA tem valor por si só, mas a implementação do Android 14 torna, na prática, difícil modificar as CAs do sistema
Localização real dos arquivos e funcionamento do APEX
- A principal mudança do Android 14 é que, se
/apex/com.android.conscrypt/cacertsexistir, os certificados passam a ser lidos desse local em vez do antigo/system/etc/security/cacerts /apexé o caminho onde são montados os Android Pony EXpress, ou seja, contêineres APEX- Módulos APEX são componentes do sistema atualizáveis de forma independente e distribuídos como contêineres imutáveis assinados
- Os certificados de CA do Android 14 passaram a fazer parte do módulo
com.android.conscrypt, a principal biblioteca TLS/SSL do Android - O funcionamento de baixo nível do APEX não é suficientemente documentado, e alguns links com detalhes essenciais estariam disponíveis apenas em sites internos do Google
- Nos testes, o conteúdo do módulo APEX parecia ser exposto diretamente a processos individuais; assim, alterar arquivos em outros locais não se refletia no que os apps viam
Fenômenos verificados no emulador do Android 14
- As imagens AOSP e “Play Services” do emulador oficial beta do Android 14 permitem acesso root
- A imagem “Google Play” é bloqueada como dispositivos OEM comuns
- É possível criar um emulador com a imagem API 34 “Google APIs” e abrir um shell root
- Cobrir os seguintes caminhos com tmpfs usando o método antigo de montagem temporária não produziu o efeito esperado
/system/etc/security/cacerts/system/etc/security/cacerts_google/apex/com.android.conscrypt/cacerts/apex/com.android.conscrypt@340818022/cacerts
- Na aba “System” de Settings → Security & Privacy → More → Encryption → Trusted Credentials, os certificados que se imaginava terem sido ocultados continuavam aparecendo
- Por exemplo, ao procurar no sistema de arquivos inteiro o arquivo
3c9a4d3b.0do certificado “ACCV”, ele não aparecia enquanto estava encoberto pela montagem, mas continuava sendo exibido nas Configurações - Ao realizar o mesmo procedimento em uma imagem do Android 13, a lista de certificados nas Configurações ficava vazia, mostrando que o método antigo funcionava como esperado
Modificar diretamente a imagem do sistema também falhou
- Ao iniciar o emulador do Android 14 com
-writable-systeme passar poradb root,adb remount,avbctl disable-verification, reinicialização etc., era possível torná-lo gravável - Depois disso, era possível apagar certificados em
/system/etc/security/cacerts/*e/system/etc/security/cacerts_google/* - Mas não era possível apagar os certificados em
/apex- Mesmo após o remount, ele permanecia somente leitura
- O comando
mount -o remount,rw ...também falhava
- A manipulação mais próxima possível era dar
umountno caminho do certificado para que ele deixasse de aparecer na saída demount - Mesmo assim, a lista “Trusted” das Configurações continuava carregando os certificados de CA
- O problema não parecia ser cache do app de Configurações, mas o mesmo comportamento do ponto de vista do repositório de certificados visto pelos apps
- Por mais que o sistema de arquivos fosse modificado, os apps continuavam vendo a lista de CAs do Google
Impactos e limitações
- No Android 14, o fluxo existente de instalar certificados de CA do sistema para depuração, engenharia reversa, testes e pesquisa deixa de funcionar pelo método tradicional
- No momento da publicação, as alternativas eram permanecer no Android 13 ou usar uma versão de SO customizada que não usasse módulos APEX para gerenciar certificados de CA
- Com o tempo, essas alternativas podem se tornar cada vez menos práticas, pois exigem divergir de componentes internos centrais do Android Mainline ou continuar usando software antigo
- Se o conteúdo dentro de módulos APEX não puder ser modificado nem com privilégios de root, a cada componente do sistema movido para APEX o controle do usuário pode diminuir
- Isso também pode ser um problema para forks do Android como GrapheneOS e LineageOS, além do Magisk e vários módulos
- No entanto, segundo a atualização no topo, discussões e pesquisas posteriores de contorno levaram a várias soluções que possibilitam injetar certificados mesmo no Android 14
- Para depurar tráfego HTTPS no Android 14, é difícil assumir apenas a injeção de CA do sistema baseada em root tradicional
1 comentários
Opiniões no Hacker News
Como alguém que trabalhou com ferramentas antigas de root no Android, ROMs customizadas universais modernas e várias tarefas relacionadas ao Android OS, acho que o título está errado agora e continuará errado no futuro
Quando se fala em root no Android, é de fato permissão de root, e você pode fazer o que quiser [1]
O root atual do Android, o Magisk, inclui até a capacidade de “modificar” código Java, então deve ser possível acessá-lo mesmo que esteja escondido bem fundo
O fato de o autor não ter conseguido não significa que seja impossível; é provável que o problema seja que o zygote esteja fazendo cache das CAs e precise ser reiniciado com
stop;start, ou que seja necessário trocar para o namespace de montagem correto antes de executar os comandosGrapheneOS e LineageOS têm acesso ao código-fonte completo, então podem mudar o que quiserem; a limitação é basicamente o incômodo de acompanhar as coisas que o Google quebra em ritmo absurdo
Espero que, à medida que o Android fique cada vez mais hostil aos usuários, especialmente aos power users, mais pessoas migrem para ROMs customizadas
Nos meus sonhos, eu criaria um fork do Android tipo “OwnerDroid”, cujo primeiro princípio do modelo de segurança não fosse “o usuário é o inimigo”; mas, embora eu tenha feito alguns pequenos tijolos, o projeto inteiro exigiria uma quantidade enorme de trabalho
[1] Com exceção de algumas proteções em nível de kernel, mas o GKI reduz esse risco
Agora isso não é mais possível
Claro que, tendo o código-fonte completo, tudo é possível, e também dá para criar do zero uma imagem de sistema Android com esse módulo desativado; GrapheneOS/LineageOS também podem responder a isso
Mas isso gera bastante trabalho novo e, se eles se afastarem da implementação do Android em componentes essenciais, pode exigir ainda mais manutenção daqui para a frente
Para a grande maioria dos usuários afetados, “primeiro compile sua própria imagem de sistema” está muito além da zona de conforto e do nível de investimento de tempo aceitável
No fim, outras soluções vão aparecer, mas provavelmente envolverão se enfiar nos namespaces para modificar individualmente as montagens do processo-alvo, ou criar e instalar um módulo APEX próprio de um jeito que o Android confie, substituindo o módulo do sistema, ou fazer hooking em apps individuais com Frida
Ainda assim, é um grande problema que torna mais difícil para o usuário ter controle total do próprio dispositivo
Partes importantes, como as verificações de root de apps bancários essenciais ou recursos relacionados ao Google, não são documentadas, e é quase impossível encontrar informação de que a combinação “modelo do celular + app do banco local + ROM customizada” foi testada e funciona bem
Sou a favor de liberdade e escolha, mas, para um usuário médio de celular, isso dificilmente é uma forma realista de agir, a menos que ele esteja disposto a gastar alguns aparelhos e vários dias de trabalho, ou já seja especialista
Sou power user em computadores, mas acho aceitável que meu celular seja mais limitado
Só que isso fica difícil quando o telefone passa a ser cada vez mais usado como dispositivo de autenticação multifator, ou quando você fica preso aos caprichos de empresas com poder de pressão maior, como bancos
Não pretendo trocar de conta bancária três vezes para encontrar apps que funcionem em um telefone com root
Se você perguntar “em que sentido forks do Android são concorrentes?”, isso significa que a estratégia está funcionando
Se o novo método lê os certificados de
/apex/com.android.conscrypt/cacertsquando esse caminho existe, parece que daria para ocultar/apex/com.android.conscrypt/cacertsapenas dos processos necessários, como já se faz hoje com bypass do SafetyNet, ocultação de root ou ocultação do Magisk, fazendo o sistema voltar ao método antigoSão território de hackers, e mesmo entre eles só uma parcela minúscula usa isso
Há muitos bons comentários aqui, mas continuo pensando em como é uma sorte que PCs não se comportem como smartphones
O Android se arruinou de forma tão completa que me sinto estranho agradecendo à Microsoft por não administrar o mundo dos PCs do jeito que o Google administra o mundo dos smartphones
O próprio Windows, comparado ao Android, chega perto de ser um bastião de estabilidade e bom senso, e você também não é obrigado a fazer upgrade antes de o hardware de fato falhar por envelhecimento
Assim como o Google, a Microsoft não controla todo o pipeline de hardware e software, mas tinha poder para impor normas pela loja ou desencorajar mudanças no ambiente com algo tipo SafetyNet, tornando a posse de um PC extremamente inconveniente
Minha lembrança é vaga sobre a Microsoft já ter enfrentado processos antitruste por coisas assim no passado, mas fico curioso para saber quando o mesmo acontecerá com o Google
A Microsoft também adicionou uma porção de DRM ao Windows, depois quebrou algumas dessas coisas, e a atestação remota também está embutida no OS
O Google mudou uma implementação interna do Android da qual os desenvolvedores não deveriam depender originalmente, deixando-os incomodados, mas a Microsoft faz esse tipo de coisa o tempo todo
É bem provável que baste esperar algumas semanas por um módulo Magisk atualizado e, sinceramente, não é tão ruim assim
Nos 5 ou 6 aparelhos que receberão o Android 14, é só não apertar o botão de atualização até lá
O Windows 11 exige TPM e Secure Boot
Ouvi dizer que alguns países em desenvolvimento exigem a instalação de CAs nacionais para fazer ataque man-in-the-middle em todas as conexões; se isso se tornar muito difícil, na prática fica mais difícil fazer o usuário desligar a própria privacidade
Estou usando um PinePhone Pro como aparelho do dia a dia
O Chase.com tenta, de forma realmente insistente, bloquear o uso de navegadores não padrão como o Librewolf e de navegadores em celulares/tablets, e tenta obrigar o uso do app móvel
Pelo menos até o WEI se tornar obrigatório, essas medidas idiotas são facilmente contornáveis, então não é um problema grave, mas, como o Chase é um banco, fico me perguntando se há margem para contestação legal
Meu primeiro palpite seria algo relacionado à conformidade com a ADA, mas não tenho certeza
Já estou tão cansado que nem sei se é brincadeira quando digo que quero processar por causa disso
Embora seja um desvio do assunto, isso é relevante porque mostra outra faceta de como é quase impossível escapar do oligopólio dos sistemas operacionais móveis
Mesmo que o nicho dos celulares Linux cresça milagrosamente para alguns poucos por cento, o Android provavelmente continuará piorando, e algo será necessário
Acho que virá uma era de servidão digital
Você usará um dispositivo fornecido por alguma empresa “benevolente”, essa empresa será dona de todos os aspectos do dispositivo, e você só poderá usá-lo como se dirige um carro se pagar
A maioria dos outros caminhos será bloqueada, a computação de uso geral ficará restrita ao “corporativo”, e a “web livre” existirá, mas será bastante técnica e hostil ao usuário
A maior parte do mercado, especialmente qualquer lugar que lide com dinheiro, vai evitá-la como uma praga
Acho que o Google matou a web aberta com isso
Ela já estava ficando meio chata de qualquer forma, mas agora é irritante que tenha ficado muito mais difícil viver sem um celular ou um navegador “aprovado”
É bom que usuários experientes saibam instalar software adicional para corrigir o problema, mas é melhor que o Chase corrija o site padrão, para que usuários iniciantes com necessidades semelhantes também sejam ajudados
Acho que, nesse ponto, o Android foi e continua sendo mais coercitivo que a Apple
Mesmo quando era possível instalar e confiar em uma nova CA raiz, alguns apps podiam ignorá-la e de fato ignoravam
Tanto iOS quanto Android permitem que apps usem fixação de certificado, mas no Android 7+ os apps, por padrão, ignoram CAs adicionadas pelo usuário desde 2016[1]
No iOS, o processo de confiar em uma CA raiz é trabalhoso, passando pela instalação de um perfil e avisos assustadores, o que em si é razoável, mas, pela minha experiência, a maioria dos apps confia nela, a menos que use fixação de certificado
[1]: https://android-developers.googleblog.com/2016/07/changes-to...
No Android, que é muito mais próximo de um computador comum que o iOS, o problema de stalkerware é enorme
Stalkerware não é barrado por prompts, explora compatibilidade retroativa e envolve todo tipo de abuso
No iOS, é surpreendentemente fácil alguém pegar seu celular emprestado por 5 minutos e, depois disso, sua privacidade em HTTPS ficar comprometida por anos
Eu quero a opção de realmente confiar em certificados de CA instalados, mas é irritante que especialmente até o Firefox, que é um navegador web, não use certificados do usuário sem uma combinação de abas e configurações escondidas
Ainda assim, pensando no risco para usuários de Android no mundo todo, é difícil dizer que esse recurso seja tão importante assim para algumas dezenas de técnicos que o usam no dia a dia
Vejo este caso mais como um efeito colateral das boas melhorias de sandboxing do Google e de um mecanismo de atualização do repositório de CAs há muito atrasado, não como uma conspiração maligna do Google para atrapalhar os planos do departamento de TI local
Um módulo Magisk provavelmente aparecerá em breve como solução alternativa, e os módulos existentes vão quebrar por um tempo, mas isso é comum depois de grandes atualizações do Android
Se necessário, você também pode escrever seu próprio módulo
Acho que isso é simplesmente como mounts funcionam
Se algo está montado em
/apex/whatevere cada app tem um namespace de montagem separado, remontar algo por cima de/apex/whateverdentro do seu próprio namespace não muda nada nos outros namespacesÉ preciso alterar diretamente o sistema de arquivos ou entrar no namespace de montagem de outro app e montar o tmpfs lá também
Montagens compartilhadas talvez ajudem, mas não tenho certeza; seria preciso olhar com mais detalhes o que realmente está acontecendo
Acho mais provável que esse resultado seja um subproduto do trabalho de namespaces/conteinerização do Google do que uma tentativa deliberada de impedir que usuários com root alterem a CA raiz
Mas o resultado final continua sendo um grande problema
A parte surpreendente aqui é o “namespace de montagem separado”
Antes, se você abrisse um shell e montasse algo no sistema de arquivos, ou o modificasse diretamente, os apps liam os arquivos desse mount sem problema
Agora, com esses arquivos cacert, isso não acontece, e no novo método a modificação direta também é impossível
Até essa mudança, eu nem sabia que apps Android usavam seus próprios namespaces de montagem
Há pouca documentação sobre exatamente como isso funciona, e também não sei se já houve um caso em que isso tenha ficado tão claro assim
Basta ver o manifest v3
Deixei uma resposta ao autor no Twitter, mas talvez ele não tenha visto, então deixo aqui também
Sou a pessoa que escreveu o post no blog sobre os certificados atualizáveis do Android 14, e esse post está linkado no artigo
Na verdade, existe uma propriedade de sistema que pode ser configurada para contornar a leitura do diretório de certificados do APEX
system.certs.enabled=trueFonte: https://android-review.googlesource.com/c/platform/framework...
Isso é uma propriedade de SO
android.os.SystemProperties, ou seja, não é um valor configurável globalmente no dispositivo viaadb, mas sim uma propriedadejava.lang.System, em outras palavras, uma configuração definida dentro de uma JVM/appPelo que vejo, para redefinir a primeira, seria preciso modificar o próprio app
É útil para testes automatizados ou para alternar a configuração entre builds debug/prod, mas não ajuda muito quando você quer fazer o dispositivo inteiro confiar em certificados de CA
Claro, se você souber uma forma de definir essa propriedade externamente e aplicá-la a todos os apps, isso funcionaria muito bem, então eu adoraria ouvir
Aliás, eu sou o autor, e não vejo essa resposta no Twitter
Bem a cara do Twitter em 2023
Parece bom para segurança e um inferno para alguns desenvolvedores, mas fico pensando no que acontece quando essa versão do Android for abandonada daqui a 2 ou 3 anos
Vamos ter que rezar para que os certificados hardcoded aguentem por mais alguns anos?
O Android 14 torna possível atualizar certificados raiz pelo Google Play, e não exige mais uma atualização OTA para adicionar ou remover certificados raiz como antes
Também existe uma solução de contorno que descobri hoje [0]
Dizem que, se você usa Android 7.0 ou inferior, talvez precise tomar medidas para continuar acessando sites protegidos por certificados da Let’s Encrypt, e recomendam instalar e usar o Firefox Mobile, que usa seu próprio armazenamento de confiança em vez do armazenamento de confiança do Android OS
[0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
[1] https://www.xda-developers.com/android-14-root-certificates-...
Porque a atualização do Google não incluía o certificado intermediário usado pela Let’s Encrypt
Isso não é uma hipótese futura, é um problema que já existe agora
Por que o Google deveria ser o árbitro final de quem eu confio?
O Google também certamente tem falhas
E, entre os provedores de certificados já aprovados, também há entidades que na prática não deveriam ser confiáveis, por terem um histórico de emitir certificados para pessoas e organizações que não deveriam tê-los
Os apps em geral não aceitam certificados de usuário, e, quando o Google Cloud ou algo relacionado mudou para certificados mais novos, alguns apps começaram a parar de funcionar
Ou seja, eles são atualizados fora do ciclo normal via Play Services e não exigem uma atualização do SO pelo OEM
A cada lançamento do Android, vejo algo sendo removido e coisas meio sem sentido sendo adicionadas
O iOS parece estar se movendo na direção oposta, então parece que eles vão se encontrar no meio aos poucos e, mais tarde, o iOS pode superar o Android em todos os aspectos
Gostaria de ouvir uma opinião sincera de quem é do lado da Apple
Tenho usado macOS ultimamente, e detesto como ele falha em aspectos muito básicos de experiência de usuário que já eram óbvios no Windows/Linux há décadas
Coisas como o Finder são simplesmente horríveis
Se eu comprar um iPhone em vez de Android na próxima geração, será que vou ter a mesma reação negativa ao iOS?
Dá para dizer que, no caso de uso de smartphone, o iOS é uma experiência de usuário mais polida e útil do que o macOS?
Tenho vontade de migrar, mas não quero desperdiçar tempo e dinheiro
O Android de antigamente era mais do que simplesmente um iOS com
.apk, e isso é realmente uma penaPara isso, ele é ok
Mas o usuário é limitado demais; eu poderia até pesquisar jailbreak, mas tento minimizar o uso do celular e fazer quase tudo no desktop
Aliás, também estou abandonando o macOS e migrando para Linux
Estou usando uma PKI pessoal para acessar softwares auto-hospedados
Coisas como servidor de e-mail, provedor de calendário, servidor de notas e ferramenta de sincronização de fotos
Preciso poder adicionar meu certificado raiz à lista de autoridades certificadoras
Não quero alterar a lista fornecida pelo sistema; só quero adicionar o meu certificado
O dispositivo é meu, então acho que deveria poder mudar o que eu quiser, se assim desejar
É bem provável que apps de e-mail e calendário também estejam incluídos nisso
O que provavelmente não vai funcionar é instalar uma CA própria para interceptar o tráfego entre um app e os servidores da empresa que fez o app
É uma pena, já que você deveria poder inspecionar o que seu próprio dispositivo está fazendo, mas o caso de uso de usar uma PKI pessoal para software auto-hospedado certamente é suportado
Parece que deve haver algum jeito
Estão criando uma ferramenta para isso no getlocalcert [1]
Como isso evita a necessidade de adicionar uma raiz de confiança, em algumas redes a abordagem de “certificados públicos sobre rede privada” acaba sendo vantajosa no geral
Sinceramente, eu não esperava que o Android fosse bloquear CAs privadas, mas foi isso que acabou acontecendo
[1] https://www.getlocalcert.net/
Não uso um telefone Android hoje, mas lembro que, no passado, era possível adicionar um certificado de CA próprio a um telefone Android apenas por uma opção nas configurações, sem root, e que pelo menos apps como navegadores web confiavam nele
Nem faz tanto tempo assim
Por isso não entendi se a necessidade de fazer root no dispositivo para instalar certificados personalizados era para algum outro uso
O HTTP Toolkit foi muito útil para extrair APIs escondidas de um péssimo app de recarga de carros elétricos da Turquia
Usei o Frida junto para contornar o SSL pinning e a detecção de root
Aí percebi que talvez o motivo de eles tentarem esconder a API fosse que aquelas APIs eram uma monstruosidade /s