Почему HttpUrlConnection бросает SSLException во время подключения к мобильным данным?

при использовании Android в HttpUrlConnection библиотека чтобы сделать запрос HTTPS, я иногда вижу следующее исключение:

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)
...

после копания в проблеме немного, я узнал, что

  • все отлично работает на wifi
  • исключение выдается только тогда, когда устройство находится на мобильном подключении к данным
  • после создания HTTPS через wifi во-первых, подключение через мобильные данные имеет тенденцию работать нормально на некоторое время
  • в проблема, похоже, происходит на небольшом количестве конкретных мобильных операторов

что могло произойти? Некоторые мобильные операторы мешают HTTPS-трафику?

18
android android-networking java ssl

1 ответов

короткий ответ::

оказывается, что некоторые мобильные операторы вернут IP-адрес для поиска DNS, который должен был потерпеть неудачу как несуществующий. Сервер, к которому подключалось приложение, иногда не разрешался, и перевозчик пытался помочь, предоставляя страницу аналогичных сайтов.

более длинный ответ:

имя хоста для сервера, к которому подключалось мое приложение, иногда не удается разрешить. Этот обычно бросают UnknownHostException для указания сбоя DNS. Я ожидаю, что это произойдет иногда, и приложение обрабатывает его. The SSLException была аномалия.

на носителях, которые перехватывают неудачные DNS-запросы, навигация веб-браузера к несуществующему хосту покажет страницу "результатов поиска", которые помогут вам найти то, что вы искали. (Некоторые DLS / кабельные интернет-провайдеры делают это тоже.) Для приложения, выполняющего запрос HTTPS, это нарушает SSL-рукопожатие, потому что удаленный хост отличается от того, что приложение ожидает.

основной причиной был неправильный DNS-сервер, который возвращал несуществующую ошибку хоста для одного из серверов, которые использовало мое приложение. Подключение через wifi казалось более надежным (из-за другой причуды того же DNS-сервера). Подключение через wifi позволит кэшировать запись DNS, тем самым временно маскируя проблему, когда мы впоследствии подключимся через мобильное соединение для передачи данных. Большую часть времени, однако, мобильный оператор перехватит неудачный поиск DNS и перенаправит нас на неожиданное имя хоста, что привело к неудачному SSL-рукопожатию.

19