Bloquea o texto en claro nas aplicacións de Android sen depender dunha VPN

Dúas cousas moi distintas chámanse bloquear o texto en claro en Android. Unha é unha política dentro dunha aplicación que ordena á súa propia pila de rede rexeitar HTTP simple. A outra é un arranxo a nivel de dispositivo que intenta protexer todo no teléfono á vez, normalmente encamiñando o tráfico por unha VPN. Resolven problemas distintos, e a segunda non pode arranxar a primeira: un túnel protexe o tramo entre o teléfono e a saída, mentres que unha aplicación que fala HTTP segue falando HTTP con todo o que está máis alá desa saída.

Dous problemas cun só nome

O primeiro problema é a carga: a aplicación escribe credenciais ou tokens nunha petición que non está cifrada de extremo a extremo, así que cada salto que pode vela pode lela. O segundo é a ruta: a aplicación pode ser impecable e aínda así queres que o operador de Wi-Fi local non aprenda nada sobre onde se conecta. Unha VPN atende o segundo e só o segundo.

Esa distinción decide quen é dono da corrección. A carga pertence a quen distribúe a aplicación, porque só ese código decide que URL chama e se valida un certificado. A ruta pertence ao dispositivo ou á rede, porque se trata de por onde viaxan os paquetes e non de que conteñen.

Ruta un: a aplicación que controlas

Se distribúes a aplicación, a corrección é unha decisión de transporte máis unha política que a impón. Apunta cada extremo a HTTPS, mantén activa a validación de nome de host e certificado, e elimina o respaldo con HTTP simple en lugar de deixalo a un indicador de configuración de distancia. Unha redirección non axuda aquí: unha petición HTTP que recibe un 301 xa enviou as súas cabeceiras e o seu corpo en claro, así que as credenciais nunca deben viaxar supoñendo que a redirección as protexerá.

En Android 7.0 e posteriores, Network Security Configuration expresa a política. O ficheiro de abaixo é a versión útil máis pequena: rexeita o texto en claro en todas partes salvo que unha excepción específica de dominio diga o contrario.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

Fai referencia a ese recurso desde o manifesto e despois le as excepcións que xa existen antes de distribuír. Un dominio de depuración antigo ou unha entrada do SDK dun provedor de pagamentos poden volver permitir en silencio o texto en claro para o host que intentabas protexer.

Dous detalles de versión convén coñecer. As aplicacións dirixidas á API 28 ou posterior xa rexeitan o texto en claro por defecto, así que unha aplicación que aínda fala HTTP simple ou apunta a un nivel de API máis antigo ou ten unha excepción nalgures. E cando hai unha configuración de seguridade de rede, o atributo de manifesto máis antigo android:usesCleartextTraffic xa non decide a cuestión, e por iso ás veces parece que cambiar ese indicador non fai nada.

Ruta dous: a aplicación que non controlas

Para unha aplicación de terceiros instalada non podes reescribir a súa configuración de seguridade cun axuste de usuario. As opcións realistas son os controis de conexión segura do propio produto, unha alternativa mantida que xa use TLS, ou unha política de dispositivo xestionado que limite o que o dispositivo pode executar. Son compromisos distintos, e só o terceiro escala a un parque de dispositivos.

As regras de rede son substitutos máis febles do que parecen. Permitir só o porto 443 non impón TLS autenticado, porque moitos protocolos de texto en claro poden trasladarse a ese porto, e bloquear o porto 80 non cobre o texto en claro noutros portos. O modo só HTTPS dun navegador tamén se limita a ese navegador, non a unha aplicación de correo ou chat aparte no mesmo teléfono.

Instalar un certificado de interceptación para que o tráfico pareza cifrado é un cambio de confianza, non unha corrección. Substitúe a autenticación do servidor da aplicación pola túa, e unha aplicación que non validaba certificados desde o principio non se repara con iso; só moviches quen pode ler o fluxo.

Onde axuda unha VPN e onde non

Un túnel é a ferramenta correcta cando o requisito é que a rede local non aprenda nada da conexión, ou que a aplicación chegue a un servizo privado ao que doutro xeito non chega. É a ferramenta equivocada para facer que un cliente HTTP fale HTTPS, porque a petición sae do túnel exactamente como entrou.

Android engade unha restrición práctica: a plataforma executa un só servizo de VPN á vez. Unha aplicación de filtrado local que ocupa ese lugar compite co túnel remoto que realmente necesitas, e cambiar entre ambos é unha operación de nivel de dispositivo e non de aplicación. Ese único lugar é unha boa razón para pór a política de carga na aplicación e reservar o túnel para a ruta.

O único caso en que ambos se solapan é un servidor privado que tamén operas. Alí un túnel pode facer privada a ruta aínda que o protocolo siga sendo texto en claro, o que reduce a exposición pero non cambia que é a carga. Trátao como redución de risco, non como cifrado dos datos.

Que probar antes de darlo por bloqueado

Empeza polo valor por defecto que sorprende: unha aplicación dirixida á API 28 ou posterior xa debería rexeitar o texto en claro, así que comproba o nivel obxectivo antes de engadir configuración que duplique un valor por defecto. Despois proba o caso de fallo a propósito: unha petición a un host HTTP simple debe fallar, non ter éxito en silencio mediante un respaldo.

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

Para o caso de éxito, confirma que a chamada HTTPS valida unha cadea de certificados real e que un proxy cun certificado non confiable se rexeita en lugar de tolerarse. Un aperto de mans que ten éxito contra calquera certificado non demostrou nada sobre a seguridade do transporte.

Para unha aplicación de terceiros, anota o límite que realmente podes impor, sexa unha política de dispositivo xestionado, unha regra de rede ou nada, e dío nos criterios de aceptación. A guía de configuración de seguridade de Android enumera os valores por defecto da plataforma e que compoñentes respectan a política, que é a parte que decide se a túa configuración fai algo de todo.