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)
...
問題を少し掘り下げた後、私はそれを学びました
何が起こっているのでしょうか?一部の携帯電話会社はHTTPSトラフィックに干渉していますか?
短い答え:
一部の携帯電話会社は、存在しないとして失敗したはずのDNSルックアップのIPアドレスを返すことが判明しました。アプリが接続していたサーバーが解決に失敗することがあり、キャリアは同様のサイトのページを提供することで支援しようとしました。
長い答え:
アプリが接続していたサーバーのホスト名が解決されないことがありました。これは通常、DNSの失敗を示すためにUnknownHostException
をスローします。私はこれが時々起こることを期待しており、アプリがそれを処理します。 SSLException
は異常でした。
失敗したDNSルックアップを傍受する通信事業者では、存在しないホストにWebブラウザーをナビゲートすると、探しているものを見つけるのに役立つ「検索結果」のページが表示されます。 (一部のDLS /ケーブルISPもこれを行います。)ただし、HTTPS要求を行うアプリの場合、リモートホストがアプリの期待値と異なるため、SSLハンドシェイクが中断されます。
根本的な原因は、私のアプリが使用していたサーバーの1つに存在しないホストエラーを返すDNSサーバーの誤動作でした。 Wi-Fi経由での接続は、より信頼性が高いようでした(同じDNSサーバーの別の癖のため)。 Wi-Fi経由で接続すると、DNSエントリをキャッシュできるため、後でモバイルデータ接続経由で接続するときに問題が一時的にマスクされます。ただし、ほとんどの場合、携帯電話会社は失敗したDNSルックアップを傍受し、予期しないホスト名にリダイレクトするため、SSLハンドシェイクが失敗しました。