☰

Safari や iOS デバイスでウェブサイトが突然開かなくなった

tag-icon • tag-icon nginx ssl lets-encrypt ios safari
Safari や iOS デバイスでウェブサイトが突然開かなくなった

最近まで問題なく動作していた Web サイトがあります。現在、ユーザーから iPhone や iPad で開かないという報告を受けています。

iOS でどのブラウザを試しても、動作しません。また、Mac マシンでブラウズすると Safari で開きません。ただし、他のブラウザは正常に動作します (Mac OSX のみ、iOS ではありません)。

サーバーの構成は次のとおりです。

DigitalOcean + Ubuntu 18.04 + Nginx + PHP 7.3 (Laravel) + Let's Encrypt SSL + HTTP2 有効化

さらに詳しく説明する前に、上記と同じタイプの構成を使用して、正常に動作し、すべてのデバイスからアクセスできる別のサーバーがあることを述べておきます。ドメイン名と IP アドレスを除けば、それらはほぼ同一です (構成とセットアップの点で)。

言及する価値があると思うもう一つの小さな追加情報は、私のユーザーがイランにいるということです。

私が確認した項目のリストは次のとおりです:

  • ドメインは、iOS および Mac から ping コマンドを使用してアクセスできます。
  • IP アドレス自体にもアクセス可能で、サイトの閲覧に使用できますが、「無効な SSL 証明書」という警告が表示されるだけです。
  • ドメインに使用された DNS はすべて iOS と Mac から ping 可能です。
  • VPN 接続を使用すると、サイトにアクセスできます。ドメイン、IP、DNS など、すべてが技術的にアクセス可能なので、これは非常に奇妙です。
  • VPN を使用する以外にも、SSL を完全にオフ/無効にした場合もサイトにアクセスできます。
  • Let's Encrypt SSL を使用している他の公開 Web サイトはすべてアクセス可能です。したがって、これは Let's Encrypt の問題ではありません。

これまで試したことは次のとおりです。

  • グーグルでたくさん検索しました。同じ種類の問題を抱えているユーザーに出会ったこともあります。ここそしてここそしてここ
  • HTTP2を無効にしてみました。
  • ファイアウォールの設定を再確認し、無効にすることも試みました。
  • GZIPを無効にしてみました。
  • ssllabs.com で SSL テストを実行しましたが、問題は見られず、動作中のサーバーと同一でした。
  • keepalive_disable "safari"nginx configで使用してみました
  • ssl_protocolsTLSv1.3のみを受け入れるか、TLSv1.0を削除するなど、値を入れ替えてみました。
  • 使ってみたssl_session_cache
  • ssl_ecdh_curveに変更してみましautoたsecp384r1
  • ssl_ciphersに変更してみましHIGH:!aNULL:!MD5;たEECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
  • ssl_session_ticketsに変更してみましonたoff
  • 使ってみたStrict-Transport-Security
  • /etc/letsencrypt/options-ssl-nginx.confcertbot が使用するコメントを試しました
  • さまざまなHTTPからHTTPSへのリダイレクト設定を試しました
  • テスト時には必ずプライベート タブを使用して、サイトにアクセスするためのキャッシュされた不正な試行が発生しないようにしました。
  • 設定ファイルに変更を加えるたびに、service nginx reload & restart を実行しました。
  • sudo reboots単純な再起動の問題ではないことを確認するために、いろいろ試しました。

最終手段として、OS を最初から再インストールし、サーバーを再度セットアップするという手間をかけました。それでも動作しません。また、設定ファイルをコピーしたわけではなく、すべてのコマンドを手動で実行し、設定ファイルを慎重に変更して、以前のセットアップからの問題が持ち込まれないようにしました。これは、Let's Encrypt (cerbot を使用) から新しい SSL リクエストを実行したことを意味します。ただし、新しいリクエストが生成されるかどうか、または前回のリクエストが送信されるかどうかはわかりません。

編集1: ここでランダムな考えを述べたいと思います。高度なネットワークについてはよくわかりませんが、イランの検閲ファイアウォールが SSL 接続に干渉し、Apple デバイスが接続を確立できない原因になっているのかもしれません。Apple は独自の方法で厳格で、Chrome や Firefox とは異なり、特定の SSL 接続を必要とすると聞きました。これら 2 つはわずかなエラーを無視するかもしれませんが、Apple デバイスはそうではありません。

編集2: Wireshark がタッピングしている間に Safari をチェックしました。何をしても、ほんの少しのパケットしか交換されないようです。また、nginx 構成で無効にしているにもかかわらず、Safari は TLSv1.0 を使用しているようです。完全にオフにする方法がまったくわかりません。Safari はサーバーとの通信に TLSv1.0 を使用しません。

編集3: 別の SSL (Comodo の 3 か月間無料 SSL トライアル プログラムを使用) を使用しようとしましたが、問題は解決しません... SSL を変更した後に同様の問題を解決したという人もいます。なぜうまくいかないのかわかりません。

編集4: DNS の問題かどうかを確認するために、ドメインの DNS サーバーを変更することにしました。理由と方法はわかりませんが、変更後、Safari は一時的にサイトを読み込むことができました。しかし、しばらくすると再び動作しなくなりました。

編集5: Google Analytics などの外部スクリプト コードをサイト内で無効にしてみましたが、うまくいきませんでした (イラン人に対してはサービスがブロックされているため)。繰り返しになりますが、外部スクリプトを無効にすることで問題が解決したという報告を読みました。

編集6: これは私のネットワークやサーバーの設定の問題ではないと信じ始めています。これは、第三者がリクエストに干渉しているように見えます。Apple とそのネットワーク処理方法については知りませんが、Apple の接続/パケットネゴシエーションが、いわば何らかの危険信号を引き起こし、イランの検閲/ファイアウォールがクライアント接続を切断しているのではないかと思います。

編集7: サーバーのデータセンターを変更し、新しい IP アドレスを設定しましたが、問題はまだ残っています :(

編集8/var/log/nginx/error.log:に設定した場合の出力ですdebug。Safari クライアントからリクエストを開始すると、これらの行が表示されます。

nginx error.log 出力

私は、php のボトルネックの問題ではないことを確認するために、php fpm を無効にしようとしました。また、php fpm 構成ファイルでいくつかのランダムなパラメータを微調整してみました。また、everythink を使用しているシステムを見ると、 CPU 使用率が急上昇net.core.somaxconnし1024たり、特定のプロセスがリストの先頭にジャンプしたりすることはなく、正常に見えます。backloghtop

編集9: Web サーバーの問題かどうかを確認するために、Nginx を Apache2 に切り替えました。そうではありませんでした。

答え1

あなたとウェブサイトの間にプロキシが存在するかどうか疑わしい場合は、ssh で -L オプションを使用してプロキシをバイパスできますか? これにより、プロキシによって変更できない、あなたとウェブサイト間の安全なトンネルが提供されます。

たとえば、デスクトップでこれを実行します: ssh -L 2222:127.0.0.1:443[メールアドレス]

このコマンドがサーバーにログインしたら、同じデスクトップでブラウザを起動してhttps://127.0.0.1:2222

サイトとその SSL 証明書が表示されている場合は、すべてが正しく設定されています。トンネルを使用していないときに、中間で誰かが SSL 接続を変更している可能性があります。

答え2

私見つかった私の問題に対する一時的な解決策。サーバーを別のホスティング/データセンターに移動したばかりです。

アップデート：実際、数か月後に問題は再発しました... どのような技術的な問題が問題を引き起こしているのか、またそれをどのように解決するのか、まったくわかりません。

アップデート2:IT ネットワークの専門家に相談したところ、問題は実際には政府のファイアウォール ルールが私のドメイン名を検出していること (誤った/間違った検閲) に依存しており、どのような Web サーバー構成や Web ホスティングを使用していても、私の手の届かないファイアウォールによってブロックされ続けるだけだと言われました。

答え3

証明書だけの問題かもしれません。SubjectAlternativeName は適切に設定されていますか? DNS 名に SubjectName のみを使用することは推奨されていません。証明書ピン留め、OSCP ステープリング、HSTP、およびその他の比較的新しい TLS 設定を使用していますか? 規制されたネットワークでは問題が発生する可能性があります。

一部のインターネット ユーザーは、SSL 検査機能を備えたプロキシを使用する必要があります。多くの企業環境では、セキュリティ ポリシーの一環として、IronPort や Bluecoat に似た製品を使用して、隠れたチャネルやマルウェアを検出しています。この方法は、アンダーグラウンド マガジン Phrack 76 の記事に由来しています。これは、各クライアントが信頼するプロキシの追加 CA ルート証明書を持ち、プロキシが各クライアントに代わって接続を再開するというシンプルな設定に要約されます。これは、MIT による「SSL のオープン」であり、イランや中国などの国はインターネット全体を監視しています。このため、PFS はなく、クライアントがサーバーの暗号をチェックすることに依存するいくつかのことが失敗する可能性があります。暗号が変更されたり、SSL が完全に削除されたりするためです。気にしない場合は、前述のオプションを削除して、サーバー証明書の設定を「エクスポート品質」にダウングレードできます。

答え4

@austin-dixon さんの回答は正しいです。そのテストは、ユーザーがいる国と同じ国から実行する必要がありますが、その国にまだいない場合は、それが選択肢にならない可能性があります。

Qualys SSLテストを使用して、少なくとも構成を検証できる可能性があります。https://www.ssllabs.com/ssltest/この場合、文字のスコアは重要ではありません。ハンドシェイク シミュレーションまで下にスクロールして、通常の状況下で Apple デバイスがどのように動作すると予想されるかを確認してください。

いずれにせよ、それはあなたがすでに疑っていることを裏付けるだけです。つまり、ユーザーとサイトの間に何かがあるということです。開発者が HTTPS を完全に無効にする以外に、この状況を回避する方法は多くありません。中間者が、サーバーが設定されているよりも弱い暗号スイートや低い TLS バージョンを必要とする可能性がありますが、その場合、どれを提案すればよいかわかりません。

関連情報