java - tls - ¿Por qué HttpUrlConnection lanza una SSLException mientras está en una conexión de datos móvil?

ssl android studio

Question

Cuando uso la biblioteca HttpUrlConnection de Android para realizar una solicitud HTTPS, a veces veo que se HttpUrlConnection la siguiente excepción:

javax.net.ssl.SSLException: SSL handshake aborted: ssl=0x5c1b18a0: I/O error during system call, Connection reset by peer
at org.apache.harmony.xnet.provider.jsse.NativeCrypto.SSL_do_handshake(Native Method)
at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:395)
...

Después de profundizar en el tema un poco, he aprendido que

• Todo funciona bien en wifi
• La excepción solo se produce cuando el dispositivo está en una conexión de datos móviles
• Después de hacer un HTTPS a través de wifi primero, la conexión a través de datos móviles tiende a funcionar bien por un tiempo
• El problema parece ocurrir en un pequeño número de operadores de telefonía móvil específicos

¿Qué podría estar pasando? ¿Algunos operadores móviles están interfiriendo con el tráfico HTTPS?

Answer 1

Respuesta corta :

Resulta que algunos operadores de telefonía móvil devolverán una dirección IP para las búsquedas de DNS que deberían haber fallado como inexistentes. El servidor al que se estaba conectando la aplicación no se resolvía a veces, y el operador intentaría ayudar proporcionando una página de sitios similares.

Respuesta más larga :

El nombre de host para el servidor al que se conectaba mi aplicación a veces no se resolvía. Esto normalmente arrojaría una UnknownHostException para indicar la falla del DNS. Espero que esto suceda de vez en cuando, y la aplicación lo maneja. La SSLException fue una anomalía.

En los operadores que interceptan búsquedas de DNS fallidas, navegar por un navegador web a un host inexistente mostrará una página de "resultados de búsqueda" con el objetivo de ayudarlo a encontrar lo que estaba buscando. (Algunos ISP de DLS / cable también hacen esto). Sin embargo, para una aplicación que realiza una solicitud HTTPS, esto rompe el protocolo de enlace de SSL porque el host remoto es diferente de lo que la aplicación espera.

La causa raíz fue un servidor DNS que no funcionaba y que devolvería un error de host inexistente para uno de los servidores que estaba usando mi aplicación. La conexión a través de wifi parecía ser más confiable (debido a otra peculiaridad del mismo servidor DNS). La conexión a través de wifi permitiría que la entrada de DNS se almacene en caché, por lo tanto, enmascarar temporalmente el problema cuando posteriormente nos conectemos a través de una conexión de datos móvil. Sin embargo, la mayoría de las veces, el operador de telefonía móvil interceptaría la búsqueda de DNS fallida y nos redirigiría a un nombre de host inesperado, lo que resultó en un protocolo de enlace SSL fallido.