web-dev-qa-db-ja.com

SafariおよびiOSデバイスでWebサイトが突然開かない

最近まで問題なく動作していたこのウェブサイトを持っています。今、ユーザーはそれが彼らのiPhoneとiPadで開かないことを報告しています。

IOSでどのブラウザーを試してもかまいませんが、機能しません。また、Macマシンで閲覧しても、Safariで開かない。ただし、他のブラウザは正常に動作します（iOSではなくMac OSXのみ）。

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

DigitalOcean + Ubuntu 18.04 + Nginx + PHP 7.3（Laravel）+ Let's Encrypt SSL + HTTP2を有効化

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

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

これが私がチェックしたもののリストです：

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

これが私がこれまでに試したことです：

  • グーグルのトン。 here と here と here で同じ種類の問題を持つユーザーに遭遇しました
  • HTTP2を無効にしてみました。
  • ファイアウォールの設定を再確認し、それを無効にしてみました。
  • GZIPを無効にしてみました。
  • 私はssllabs.comでsslテストを行いましたが、問題はなく、実際のサーバーと同じです。
  • Nginx設定でkeepalive_disable "safari"を使用してみました
  • ssl_protocolsの値を入れ替えてみました。たとえば、TLSv1.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を使用して試しました
  • Certbotが使用するコメント/etc/letsencrypt/options-ssl-nginx.confを試しました
  • 別のHTTPからHTTPSへのリダイレクト設定を試しました
  • 私はテスト時にプライベートタブを使用して、サイトにアクセスするためのキャッシュされた不正な試みの種類を確認していないことを確認しました。
  • 設定ファイルに変更を加えるたびに、nginxのリロードと再起動を行いました。
  • 単純な再起動の問題ではないことを確認するために、Sudo rebootsをたくさん行いました。

最後の手段として、私はOSを最初から再インストールし、サーバーを再セットアップするという問題も経験しました。それでも動作しません。いいえ、構成ファイルをコピーしなかったので、すべてのコマンドを手動で実行し、構成ファイルを慎重に変更して、以前のセットアップで問題が発生しないようにしました。これはまた、Let's Encrypt（cerbotを使用）から新しいSSLリクエストを実行したことを意味します。新しいものを生成するのか、前回のものをあなたに送るのかはわかりませんが。

EDIT 1：ここでランダムな考えを投げたいです。高度なネットワーキングについては本当に知りませんが、イランの検閲ファイアウォールの何かがSSL接続に干渉しているため、Appleデバイスが接続の確立に失敗します。Appleは独自の方法で厳密であり、chromeおよびfirefoxとは異なり、特定のSSL接続が必要です。これら2つはわずかなエラーを無視する可能性がありますが、Appleデバイスはない.

EDIT 2：Wiresharkがタップしている間にSafariをチェックしました。私が何をしても、交換されるパケットはほとんどないようです。また、nginx configで無効にしたにもかかわらず、SafariがTLSv1.0を使用しているようです。完全にオフにする方法がわからないので、Safariはそれを使用してサーバーと通信しようとさえしません。

EDIT 3：別のSSL（comodoの3か月の無料のssl試用プログラムを使用）を試してみましたが、問題はまだあります...彼らはSSLを変更した後、いくつかの同様の問題を解決したと述べました。なぜうまくいかないのか分かりません。

EDIT 4：ドメインのDNSサーバーを変更して、DNSの問題かどうかを確認することにしました。理由と方法はわかりませんが、変更した後、Safariがサイトを短時間で読み込むことができました。しかし、しばらくすると再び機能しなくなりました。

EDIT 5：Googleアナリティクスなど、私のサイトで外部スクリプトコードを無効にすることはできません（サービスがイランではブロックされているためです）。繰り返しになりますが、外部スクリプトを無効にすることで問題が修正されたことを示唆する人々の報告を読みました。

EDIT 6：これは私の側のネットワークまたはサーバー構成の問題ではないと信じ始めています。リクエストを妨害しているサードパーティのようです。 Appleとそれがネットワーキングを処理する方法についてはわかりませんが、Apple接続/パケット化のネゴシエーションは、いわばある種の赤旗を引き起こしています。これにより、イランの検閲/ファイアウォールはクライアント接続をドロップします。

EDIT 7：新しいIPアドレスでサーバーのデータセンターを変更しました。問題はまだ存在します:(

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

nginx error.log output

Php fpmを無効にして、phpのボトルネックの問題ではないことを確認しました。また、php fpm設定ファイルでnet.core.somaxconnを1024にバンピングしたり、backlogを増やしたりするなど、いくつかのランダムなパラメーターを微調整しようとしました。また、htopを使用してシステムを監視すると、everythinkは正常に見え、CPU使用率が急上昇することも、特定のプロセスがリストの先頭にジャンプすることもありません。

EDIT 9：NginxをApache2にスワップして、ウェブサーバーの問題かどうかを確認しました。まあ、そうではなかった。

nginxssllets-encryptiossafari
2
xperator

あなたとウェブサイトの間のプロキシを疑っているので、sshで-Lオプションを使用してプロキシをバイパスできますか？それはあなたとあなたのウェブサイトの間にプロキシーによって変更できない安全なトンネルを提供します。

たとえば、これをデスクトップで実行します。ssh -L 2222：127.0.0.1：443 [email protected]

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

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

1
Austin Dixon

私found私の問題の一時的な解決策。サーバーを別のホスティング/データセンターに移動しました！

更新：実際、問題は数か月後に再び現れました...問題の原因となっている技術的な問題やその修正方法は本当にわかりません。

0
xperator

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

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

0
bbaassssiiee

@ austin-dixonの答えは正しい方向にあります。そのテストは、ユーザーがいる国と同じ国から行う必要があります。その国にまだいない場合、これは選択肢にならない場合があります。

https://www.ssllabs.com/ssltest/ にあるQualys SSLテストを使用することで、少なくとも構成を検証できる場合があります。この場合、文字のスコアは関係ありません。下にスクロールして[Handshake Simulation]までスクロールし、Appleデバイスが通常の状況でどのように動作することが期待されるかを確認します。

どちらの方法でも、既に疑わしいものを確認するだけで、それらのユーザーとサイトの間に何かがあることを確認できます。開発者がHTTPSを完全に無効にする以外に、この状況を回避する方法は多くありません。真ん中の人が、サーバーが構成されているよりも弱い暗号スイートまたは低いTLSバージョンのいくつかを必要とする可能性がありますが、その場合、どの暗号スイートを提案すべきかわかりません。

0
wrk2bike