Bloquear el texto en claro en apps de Android sin depender de una VPN

Dos cosas muy distintas se llaman bloquear el texto en claro en Android. Una es una política dentro de una app que ordena a su propia pila de red que rechace HTTP simple. La otra es un arreglo a nivel de dispositivo que intenta proteger todo el teléfono a la vez, normalmente enrutando el tráfico por una VPN. Resuelven problemas distintos, y la segunda no puede arreglar la primera: un túnel protege el tramo entre el teléfono y la salida, mientras que una app que habla HTTP sigue hablando HTTP con todo lo que hay más allá de esa salida.

Dos problemas con un solo nombre

El primer problema es la carga: la app escribe credenciales o tokens en una petición que no está cifrada de extremo a extremo, así que cada salto que puede verla puede leerla. El segundo es la ruta: la app puede ser impecable y aun así quieres que el operador de Wi-Fi local no aprenda nada sobre dónde se conecta. Una VPN atiende el segundo y solo el segundo.

Esa distinción decide quién es dueño de la corrección. La carga pertenece a quien distribuye la app, porque solo ese código decide qué URL llama y si valida un certificado. La ruta pertenece al dispositivo o a la red, porque se trata de por dónde viajan los paquetes y no de qué contienen.

Ruta uno: la app que controlas

Si distribuyes la app, la corrección es una decisión de transporte más una política que la impone. Apunta cada extremo a HTTPS, mantén activa la validación de nombre de host y certificado, y elimina el respaldo con HTTP simple en lugar de dejarlo a un indicador de configuración de distancia. Una redirección no ayuda aquí: una petición HTTP que recibe un 301 ya ha enviado sus cabeceras y su cuerpo en claro, así que las credenciales nunca deben viajar suponiendo que la redirección las protegerá.

En Android 7.0 y posteriores, Network Security Configuration expresa la política. El archivo de abajo es la versión útil más pequeña: rechaza el texto en claro en todas partes salvo que una excepción específica de dominio diga lo contrario.

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

Haz referencia a ese recurso desde el manifiesto y después lee las excepciones que ya existen antes de distribuir. Un dominio de depuración antiguo o una entrada del SDK de un proveedor de pagos pueden volver a permitir en silencio el texto en claro para el host que intentabas proteger.

Dos detalles de versión conviene conocer. Las apps dirigidas a API 28 o posterior ya rechazan el texto en claro por defecto, así que una app que todavía habla HTTP simple o apunta a un nivel de API más antiguo o tiene una excepción en alguna parte. Y cuando hay una configuración de seguridad de red, el atributo de manifiesto más antiguo android:usesCleartextTraffic ya no decide la cuestión, y por eso a veces parece que cambiar ese indicador no hace nada.

Ruta dos: la app que no controlas

Para una app de terceros instalada no puedes reescribir su configuración de seguridad con un ajuste de usuario. Las opciones realistas son los controles de conexión segura del propio producto, una alternativa mantenida que ya use TLS, o una política de dispositivo gestionado que limite lo que el dispositivo puede ejecutar. Son compromisos distintos, y solo el tercero escala a un parque de dispositivos.

Las reglas de red son sustitutos más débiles de lo que parecen. Permitir solo el puerto 443 no impone TLS autenticado, porque muchos protocolos de texto en claro pueden trasladarse a ese puerto, y bloquear el puerto 80 no cubre el texto en claro en otros puertos. El modo solo HTTPS de un navegador también se limita a ese navegador, no a una app de correo o chat aparte en el mismo teléfono.

Instalar un certificado de interceptación para que el tráfico parezca cifrado es un cambio de confianza, no una corrección. Sustituye la autenticación del servidor de la app por la tuya, y una app que no validaba certificados desde el principio no se repara con eso; solo has movido quién puede leer el flujo.

Dónde ayuda una VPN y dónde no

Un túnel es la herramienta correcta cuando el requisito es que la red local no aprenda nada de la conexión, o que la app llegue a un servicio privado al que de otro modo no llega. Es la herramienta equivocada para hacer que un cliente HTTP hable HTTPS, porque la petición sale del túnel exactamente como entró.

Android añade una restricción práctica: la plataforma ejecuta un solo servicio de VPN a la vez. Una app de filtrado local que ocupa ese lugar compite con el túnel remoto que realmente necesitas, y cambiar entre ambos es una operación de nivel de dispositivo y no de app. Ese único lugar es una buena razón para poner la política de carga en la app y reservar el túnel para la ruta.

El único caso en que ambos se solapan es un servidor privado que también operas. Ahí un túnel puede hacer privada la ruta aunque el protocolo siga siendo texto en claro, lo que reduce la exposición pero no cambia qué es la carga. Trátalo como reducción de riesgo, no como cifrado de los datos.

Qué probar antes de darlo por bloqueado

Empieza por el valor por defecto que sorprende: una app dirigida a API 28 o posterior ya debería rechazar el texto en claro, así que comprueba el nivel objetivo antes de añadir configuración que duplique un valor por defecto. Luego prueba el caso de fallo a propósito: una petición a un host HTTP simple debe fallar, no tener éxito en silencio mediante un respaldo.

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

Para el caso de éxito, confirma que la llamada HTTPS valida una cadena de certificados real y que un proxy con un certificado no confiable se rechaza en lugar de tolerarse. Un apretón de manos que tiene éxito contra cualquier certificado no ha demostrado nada sobre la seguridad del transporte.

Para una app de terceros, anota el límite que realmente puedes imponer, sea una política de dispositivo gestionado, una regla de red o nada, y dilo en los criterios de aceptación. La guía de configuración de seguridad de Android enumera los valores por defecto de la plataforma y qué componentes respetan la política, que es la parte que decide si tu configuración hace algo en absoluto.