Android 17 e privacidade: o que muda para devs na prática

Toda vez que o seu celular conecta a um site via HTTPS, existe uma janela de exposição que pouca gente enxerga: o handshake TLS inicial revela o domínio antes do canal criptografado subir. O Android 17 finalmente fecha essa porta. Segundo o Sapo.pt, a Google vai introduzir suporte generalizado ao protocolo ECH (Encrypted Client Hello) combinado com DNS privado em nível de sistema — e isso muda o jogo para quem se preocupa com privacidade de rede. Mas o impacto vai além do consumidor comum: como dev, isso afeta diretamente como você testa, depura e desenvolve aplicações Android.

O que é o ECH e por que ele importa agora

Quando você acessa https://exemplo.com, o cliente TLS envia um campo chamado Server Name Indication (SNI) em texto puro no ClientHello. Esse campo é necessário porque um mesmo IP pode hospedar centenas de domínios via virtual hosting. O problema? Qualquer intermediário — operadora, proxy corporativo, atacante na mesma Wi-Fi — vê para onde você está indo, mesmo sem descriptografar o conteúdo.

O ECH resolve isso criptografando o ClientHello inteiro usando uma chave pública publicada via HTTPS RR (DNS Resource Record) do domínio parent. O servidor CDN expõe uma chave ECH para que clientes consigam criptografar o SNI antes de mandar na rede. O resultado prático: sua operadora vê apenas o domínio do CDN (ex.: cloudflare-ech.com), não o site real.

Na minha experiência, quando combino ECH + DNS-over-HTTPS (DoH) + DNS-over-TLS (DoT), minha análise de tráfego no Wireshark mostra apenas IPs e conexões criptografadas opacas. Isso é o ideal para quem trabalha com dados sensíveis ou está pesquisando em rede não confiável.

Como verificar se uma URL suporta ECH hoje

Antes de atualizar para o Android 17, dá pra testar o suporte ECH em qualquer máquina. Esse foi um dos primeiros scripts que rodei no meu setup Linux:

# Verifica suporte ECH em um domínio via curl
curl --ech true -v https://cloudflare.com 2>&1 | grep -i ech

# Inspeciona o registro HTTPS RR via dnsdiag
pip install dnspython
python3 -c "
import dns.resolver
answers = dns.resolver.resolve('cloudflare.com', 'HTTPS')
for rdata in answers:
    print(rdata.to_text())
"

# Ou usa o TLS-Analyzer (Java)
git clone https://github.com/tls-attacker/TLS-Analyzer.git
cd TLS-Analyzer
./run.sh -connect cloudflare.com:443 -ech

Se o output mostrar um campo ech= com parâmetros válidos, o domínio já suporta. Cloudflare, Mozilla e alguns sites grandes já estão prontos.

DNS privado em nível de sistema: o que muda para devs

O Android já tinha DNS-over-TLS desde a versão 9, mas era opcional e mal documentado. O usuário precisava entrar em configurações avançadas e digitar manualmente o hostname do resolvedor. Com o Android 17, a expectativa — confirmada pela Google — é que o DoH/DoT venha ativado por padrão em perfis onde a operadora oferecer suporte.

Para devs, isso significa que DNS leaks em testes de integração vão ficar mais difíceis de detectar. Se você roda uma suíte de testes E2E que valida resolução DNS, precisa passar a usar resolvedores locais (dnsmasq, Unbound, CoreDNS) e ignorar a configuração do device. Eu já peguei bug em produção por causa disso: o app resolvia um nome via DNS público do device, mas no ambiente real o split-horizon DNS respondia outro IP.

Comparação rápida: DNS plain, DoT, DoH e DoQ

Permissões para varrer rede local: fim do mapeamento silencioso

Outro ponto crítico que a fonte original destaca: apps Android podiam, até agora, fazer broadcast UDP em portas como 5353 (mDNS/Bonjour), 1900 (SSDP/UPnP) e 3000-3010 (vários fabricantes) sem nenhuma permissão. Isso permitia mapear TVs, consoles, câmeras, impressoras, IoT inteiro — muitas vezes com informações de modelo e versão expostas.

O Android 17 vai exigir permissão explícita para esse varrimento, e fornecer um seletor nativo. Isso é ótimo para o usuário, mas vai quebrar apps malfeitos que dependiam de descoberta automática. Se você mantém um app que descobre dispositivos Chromecast, Sonos ou smart TVs, prepare-se.

Na Prática: como ajustar seu app para a nova API

1. Declare no AndroidManifest.xml a nova permissão android.permission.NEARBY_DEVICES (ou a específica para varredura de rede local).
2. Solicite runtime permission antes de iniciar o discovery — não assuma que basta estar no manifest.
3. Use o seletor nativo do sistema em vez de fazer broadcast próprio. O usuário confia mais no picker do OS do que numa UI customizada.
4. Implemente fallback gracioso: se a permissão for negada, seu app ainda precisa funcionar (mesmo que com menos recursos).
5. Teste em devices com Android 17 via emulador — o comportamento vai mudar silenciosamente se você não validar.

No meu último projeto com smart home, eu já tinha implementado um picker próprio porque o cliente queria branding. Erro meu — quando o Android 17 chegou, tive que refatorar. Lição: prefira APIs nativas sempre que existir, mesmo que a UI não fique 100% na marca.

Transparência de Certificados obrigatória: CT vai virar padrão

Certificate Transparency (CT) é um framework público e auditável onde cada certificado TLS emitido é logado. Browsers já exigem SCTs (Signed Certificate Timestamps) há anos. O Android 17 finalmente traz essa obrigatoriedade em nível de sistema para apps que usam HttpsURLConnection, OkHttp e APIs nativas TLS.

Para devs, isso significa:

• Certificados emitidos por CAs pequenas ou autoassinados vão ser rejeitados sem logs CT válidos.
• Em ambiente de desenvolvimento, você precisa configurar um proxy MITM (mitmproxy, Burp) com CT bypass local — senão nada funciona.
• Apps que usam certificate pinning precisam atualizar as chains para incluir SCTs válidos.

Exemplo: configurando mitmproxy com CT bypass em dev

# ct_bypass.py — adicione via -s no mitmdump
from mitmproxy import http, ctx

class CTBypass:
    def load(self, loader):
        ctx.options.tls_version_client_min = "TLS1_2"

    def tls_clienthello(self, data):
        # Em dev, logue apenas para debug
        ctx.log.info(f"TLS handshake: {data.sni}")

addons = [CTBypass()]

# Comando: mitmdump -s ct_bypass.py --set block_global=false

Cuidado com essa armadilha: nunca desabilite CT em produção. Aparentemente é “só mais um check”, mas sem ele um atacante com uma CA comprometida consegue interceptar tráfego sem que o app perceba.

2G desativado pela operadora: o fim dos SMS blasters

A parte que mais me interessou: o Android 17 permite que a operadora desative 2G remotamente via rede. Isso ataca diretamente os SMS blasters — aqueles equipamentos portáteis que forçam o telefone a downgrade para 2G para injetar SMS de phishing sem filtro.

Na minha vivência com segurança, já vi relatórios de como 2G é um protocolo fundamentalmente quebrado: criptografia fraca (A5/1 pode ser quebrada em tempo real), aceita comandos OTA sem autenticação forte, e a rede pode forçar o handset a desabilitar criptografia via signaling. Bloquear 2G no nível da operadora é a única solução real — desativar no device é paliativo porque o atacante controla o signaling.

Erros Comuns que devs cometem em segurança de rede Android

• Confiar em NetworkSecurityConfig padrão e achar que está seguro. O config padrão só bloqueia cleartext em domínios explícitos — não força TLS 1.3 nem CT.
• Não testar em redes adversariais. Se seu app só foi testado em Wi-Fi de escritório, prepare-se para surpresas em redes de hotel, café, aeroporto.
• Ignorar mDNS em apps de IoT. Vazar a topologia da rede do usuário é grave, especialmente em escritórios pequenos.
• Não invalidar pins de certificado quando a CA rotaciona. Android 17 pode forçar revalidação mais agressiva, quebrando apps com pin velho.
• Assumir que DNS-over-HTTPS está habilitado. Em testes locais, garanta que o DNS está sendo resolvido pelo seu servidor, não pelo do device.

FAQ — Perguntas que devs realmente fazem

O Android 17 vai quebrar apps que dependem de descoberta de rede local?
Sim, se eles não atualizarem para o novo modelo de permissões. O picker nativo vai substituir broadcasts UDP diretos, então apps precisam se adaptar com a permissão NEARBY_DEVICES e runtime request explícita.

Como testar suporte ECH no meu app antes do release?
Use o script que mostrei acima com curl e TLS-Analyzer. Para Android, configure o device com DoH (1.1.1.1 ou dns.google) e capture o tráfego em proxy local. Se o SNI aparecer criptografado no ClientHello, ECH está ativo.

Posso continuar usando 2G em casos legítimos?
Se você depende de 2G para IoT industrial, sistemas legados ou redes rurais, o Android 17 permite override manual do usuário. Mas em consumer devices, 2G vai sumir gradualmente — e isso é bom para a segurança como um todo.

Certificate Transparency vai me custar mais caro em certificados?
Não diretamente. CAs públicas já emitem com SCTs por padrão. O custo maior será na sua infra de dev: você precisa rodar um CT log local (ou usar serviço público) para certificados autoassinados em testes de integração.

Minha operadora vai ativar DoH automaticamente?
Depende. Operadoras que já oferecem DNS seguro (como as europeias sob GDPR) provavelmente vão ativar por padrão. Outras podem deixar opcional. O Android 17 vai respeitar essa configuração, mas permitirá override manual nas settings de rede.

O que isso significa para o ecossistema dev

No agregado, o Android 17 não é apenas “mais privacidade” — é um shift de paradigma: a Google está empurrando a responsabilidade de segurança da rede para baixo na stack, onde ela sempre deveria ter estado. Apps vão precisar ser mais explícitos sobre que tipo de acesso querem, e devs que ainda tratam permission model como afterthought vão pagar o preço.

Eu vejo isso como positivo. Toda vez que o OS eleva o padrão, a indústria se ajusta. Lembra quando o Android 6 introduziu runtime permissions? Foi caos por uns dois anos, mas hoje nenhum app sério funciona sem o modelo correto. O mesmo vai acontecer agora com descoberta de rede e validação de certificados.

Se você mantém um app Android, comece hoje a mapear onde ele depende de varredura de rede local, certificados autoassinados, ou DNS não criptografado. O Android 17 vai chegar antes do que você imagina, e refatorar permission model em cima da hora é sempre doloroso. Eu já aprendi isso na pele — e você pode aprender sem repetir o mesmo erro.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.