Website öffnet sich plötzlich nicht mehr in Safari und auf iOS-Geräten

Question

Ich habe diese Website, die bis vor kurzem einwandfrei funktioniert hat. Jetzt melden Benutzer, dass sie sich auf ihren iPhones und iPads nicht öffnet.

Egal welchen Browser Sie unter iOS ausprobieren, es funktioniert einfach nicht. Außerdem wird es nicht in Safari geöffnet, wenn Sie auf einem Mac surfen. Andere Browser funktionieren jedoch einwandfrei (nur Mac OSX, nicht iOS).

Hier ist die Serverkonfiguration:

DigitalOcean + Ubuntu 18.04 + Nginx + PHP 7.3 (Laravel) + Let’s Encrypt SSL + HTTP2 aktiviert

Bevor ich weiter erkläre, möchte ich erwähnen, dass ich mit derselben Konfiguration wie oben einen anderen Server habe, der einwandfrei läuft und von allen Geräten aus zugänglich ist. Sie sind (in Bezug auf Konfiguration und Einrichtung) fast identisch, abgesehen natürlich vom Domänennamen und der IP-Adresse.

Eine weitere kleine Zusatzinformation, die meiner Meinung nach erwähnenswert ist, ist, dass sich meine Benutzer im Iran befinden.

Hier ist eine Liste der Dinge, die ich überprüft habe:

• Auf die Domäne kann über iOS und Mac per Ping-Befehl zugegriffen werden.
• Auf die IP-Adresse selbst kann ebenfalls zugegriffen werden und sie kann zum Durchsuchen der Site verwendet werden. Es wird lediglich die Warnung „ungültiges SSL-Zertifikat“ angezeigt.
• Die für die Domäne verwendeten DNS sind alle von iOS und Mac aus pingbar.
• Wenn eine VPN-Verbindung verwendet wird, kann auf die Site zugegriffen werden. Das ist wirklich seltsam, da technisch alles erreichbar ist, die Domäne, die IP und der DNS.
• Abgesehen von der Verwendung eines VPN kann auf die Site auch zugegriffen werden, wenn SSL vollständig ausgeschaltet/deaktiviert ist.
• Andere öffentliche Websites, die Let’s Encrypt SSL verwenden, sind alle zugänglich. Es kann also kein Problem mit Let’s Encrypt sein.

Folgendes habe ich bisher versucht:

• Tonnenweise gegoogelt. Ich bin sogar auf einen Benutzer mit dem gleichen Problem gestoßenHierUndHierUndHier
• Ich habe versucht, HTTP2 zu deaktivieren.
• Ich habe meine Firewall-Einstellungen doppelt geprüft und sogar versucht, sie zu deaktivieren.
• Ich habe versucht, GZIP zu deaktivieren.
• Ich habe einen SSL-Test auf ssllabs.com durchgeführt und es zeigt kein Problem und es ist identisch mit meinem Arbeitsserver.
• Versucht, es keepalive_disable "safari"in der Nginx-Konfiguration zu verwenden
• Ich habe versucht, ssl_protocolsWerte auszutauschen, z. B. nur TLSv1.3 zu akzeptieren oder TLSv1.0 wegzulassen.
• Versucht mitssl_session_cache
• Versuchte zu ssl_ecdh_curveändern autoundsecp384r1
• Versuchte zu ssl_ciphersändern HIGH:!aNULL:!MD5;undEECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
• Versuchte zu ssl_session_ticketsändern onundoff
• Versucht mitStrict-Transport-Security
• Habe versucht, Kommentare abzugeben /etc/letsencrypt/options-ssl-nginx.conf, die von Certbot verwendet werden
• Habe verschiedene Umleitungseinstellungen für HTTP zu HTTPS ausprobiert
• Ich habe beim Testen darauf geachtet, einen privaten Tab zu verwenden, um sicherzustellen, dass es sich nicht um einen fehlerhaften zwischengespeicherten Versuch handelt, die Site zu erreichen.
• Ich habe den Dienst „nginx“ jedes Mal neu geladen und neu gestartet, wenn ich eine Änderung an den Konfigurationsdateien vorgenommen habe.
• Ich habe viel getan, sudo rebootsum sicherzustellen, dass es sich nicht einfach um ein Neustartproblem handelt.

Als letzten Ausweg habe ich mir sogar die Mühe gemacht, das Betriebssystem komplett neu zu installieren und den Server erneut einzurichten. Funktioniert immer noch nicht.Und nein, ich habe meine Konfigurationsdateien nicht kopiert. Ich habe jeden Befehl manuell ausgeführt und die Konfigurationsdateien sorgfältig geändert, um sicherzustellen, dass ich keine Probleme aus dem vorherigen Setup mitbringe. Das bedeutet auch, dass ich eine neue SSL-Anfrage von Let's Encrypt gestellt habe (mit Cerbot). Obwohl ich nicht weiß, ob sie eine neue generieren oder Ihnen die vom letzten Mal senden.

BEARBEITEN 1: Ich möchte hier einen zufälligen Gedanken einwerfen. Ich kenne mich mit fortgeschrittenen Netzwerken nicht wirklich aus, aber vielleicht manipuliert etwas von den iranischen Zensur-Firewalls die SSL-Verbindung und führt dazu, dass Apple-Geräte keine Verbindung herstellen können. Ich habe gehört, dass Apple auf seine Weise streng ist und im Gegensatz zu Chrome und Firefox eine bestimmte SSL-Verbindung erfordert. Diese beiden ignorieren möglicherweise einen kleinen Fehler, aber Apple-Geräte tun das nicht.

BEARBEITEN 2: Ich habe Safari überprüft, während Wireshark tippt. Es scheint, dass nur wenige Pakete ausgetauscht werden, egal was ich tue. Außerdem scheint Safari TLSv1.0 zu verwenden, obwohl ich es in der Nginx-Konfiguration deaktiviert habe. Ich weiß wirklich nicht, wie ich es vollständig ausschalten kann, sodass Safari nicht einmal versucht, es zur Kommunikation mit dem Server zu verwenden.

BEARBEITEN 3: Ich habe versucht, ein anderes SSL zu verwenden (mit dem 3-monatigen kostenlosen SSL-Testprogramm von Comodo), aber das Problem besteht immer noch ... Ich habe gelesen, dass einige Leute sagen, sie hätten ähnliche Probleme gelöst, nachdem sie ihr SSL geändert haben. Ich weiß nicht, warum es bei mir nicht funktioniert.

BEARBEITEN 4: Ich habe beschlossen, die DNS-Server der Domäne zu ändern, um zu sehen, ob es ein DNS-Problem ist. Ich weiß nicht, warum und wie, aber nachdem ich sie geändert hatte, konnte Safari die Site kurz laden. Aber nach einiger Zeit funktionierte es nicht mehr.

BEARBEITEN 5: Ich hatte kein Glück mit dem Deaktivieren externer Skriptcodes auf meiner Site, wie z. B. Google Analytics (weil deren Dienst für Iraner irgendwie gesperrt ist). Ich habe auch Berichte von Leuten gelesen, die darauf hindeuten, dass einige ihr Problem behoben haben, indem sie externe Skripte deaktiviert haben.

BEARBEITEN 6: Ich fange an zu glauben, dass dies kein Netzwerk- oder Serverkonfigurationsproblem meinerseits ist. Es sieht wirklich so aus, als würde ein Dritter die Anfrage stören. Ich weiß nicht, wie Apple mit Netzwerken umgeht, aber ich denke, dass die Verbindungs-/Paketverhandlungen von Apple sozusagen eine Art rote Fahne auslösen und die iranische Zensur/Firewall dazu bringen, die Client-Verbindung zu unterbrechen.

BEARBEITEN 7: Ich habe sogar das Rechenzentrum des Servers mit einer neuen IP-Adresse geändert. Das Problem besteht immer noch :(

BEARBEITEN 8: Dies ist die /var/log/nginx/error.logAusgabe, wenn es auf gesetzt ist debug. Diese Zeilen werden angezeigt, wenn ich eine Anfrage von einem Safari-Client initiiere.

Ich habe versucht, PHP FPM zu deaktivieren, um sicherzustellen, dass es sich nicht um ein PHP-Engpassproblem handelt. Außerdem habe ich versucht, einige zufällige Parameter zu optimieren, z. B. das Erhöhen net.core.somaxconnoder 1024Erhöhen backlogvon PHP FPM-Konfigurationsdateien. Auch wenn ich das System beobachte, htopsieht alles normal aus, keine CPU-Auslastungsspitzen und kein bestimmter Prozess springt an den Anfang der Liste.

BEARBEITEN 9: Ich habe Nginx gegen Apache2 ausgetauscht, um zu prüfen, ob es ein Webserverproblem ist. Das war nicht der Fall.

Answer 1

Da Sie den Proxy zwischen Ihnen und der Website nicht kennen, können Sie ihn umgehen, indem Sie die Option -L in SSH verwenden? Dadurch wird ein sicherer Tunnel zwischen Ihnen und Ihrer Website bereitgestellt, der vom Proxy nicht geändert werden kann.

Führen Sie beispielsweise Folgendes auf Ihrem Desktop aus: ssh -L 2222:127.0.0.1:443[email geschützt]

Sobald sich dieser Befehl bei Ihrem Server angemeldet hat, starten Sie den Browser auf demselben Desktop, umhttps://127.0.0.1:2222

Wenn Sie jetzt Ihre Site und ihr SSL-Zertifikat sehen, ist alles richtig eingerichtet – es ist jemand dazwischen, der Ihre SSL-Verbindung ändert, wenn Sie den Tunnel nicht verwenden.

Answer 2

ICHgefundeneine vorübergehende Lösung für mein Problem. Ich habe den Server gerade zu einem anderen Hosting/Rechenzentrum verschoben!

Aktualisieren:Tatsächlich ist das Problem nach einigen Monaten erneut aufgetreten ... Ich weiß wirklich nicht, welches technische Problem das Problem verursacht oder wie ich es beheben kann.

Aktualisierung 2:Ich habe mit einem IT-Netzwerkexperten gesprochen und dieser hat mir gesagt, dass das Problem eigentlich darin liegt, dass die Firewall-Regeln der Regierung meinen Domänennamen aufgreifen (falsche/unzutreffende Zensur). Und egal, welche Webserver-Konfiguration oder welches Webhosting ich verwende, es wird einfach immer von Firewalls blockiert, die außerhalb meiner Reichweite liegen.

Answer 3

Es könnte einfach am Zertifikat liegen. Haben Sie SubjectAlternativeName richtig eingestellt? Nur den SubjectName für den DNS-Namen zu verwenden, ist veraltet. Verwenden Sie Certificate Pinning, OSCP-Stapling, HSTP und andere relativ neue TLS-Einstellungen? Dies könnte in regulierten Netzwerken zu Problemen führen.

Einige Internetnutzer müssen einen Proxy mit SSL-Prüfung verwenden. Viele Unternehmensumgebungen verwenden Produkte wie IronPort oder Bluecoat, um im Rahmen ihrer Sicherheitsrichtlinie verdeckte Kanäle und Malware zu erkennen. Die Vorgehensweise dazu stammt aus einem Artikel im Underground-Magazin Phrack 76. Es läuft auf ein einfaches Setup hinaus, bei dem jeder Client ein zusätzliches CA-Stammzertifikat des Proxys hat, dem er vertraut. Der Proxy wiederum initiiert Verbindungen im Namen jedes Clients neu und „öffnet das SSL“ durch das MIT. Länder wie der Iran und China überwachen das Internet im Großen und Ganzen. Aus diesem Grund gibt es kein PFS, und einige Dinge können fehlschlagen, die davon abhängen, dass der Client die Verschlüsselung der Server überprüft, weil sie geändert oder SSL sogar vollständig entfernt wurde. Wenn Sie sich nicht darum kümmern, können Sie Ihre Serverzertifikateinstellungen auf „Exportqualität“ herabstufen, indem Sie die genannten Optionen entfernen.

Answer 4

Die Antwort von @austin-dixon ist in die richtige Richtung gerichtet. Dieser Test müsste in demselben Land durchgeführt werden, in dem sich die Benutzer befinden, was möglicherweise keine Option ist, wenn Sie sich nicht bereits in diesem Land befinden.

Möglicherweise können Sie die Konfiguration zumindest validieren, indem Sie den Qualys SSL-Test unterhttps://www.ssllabs.com/ssltest/. Die Buchstabenbewertung spielt in diesem Fall keine Rolle. Scrollen Sie einfach nach unten zu „Handshake-Simulation“ und sehen Sie, wie die Apple-Geräte unter normalen Umständen voraussichtlich funktionieren.

So oder so bestätigt das nur, was Sie bereits vermuten, nämlich dass etwas zwischen diesen Benutzern und der Site ist. Es gibt für einen Entwickler nicht viele Möglichkeiten, diese Situation zu umgehen, außer HTTPS vollständig zu deaktivieren. Es ist möglich, dass der Mann in der Mitte einige der schwächeren Verschlüsselungssammlungen oder niedrigere TLS-Versionen benötigt, als der Server konfiguriert ist, aber ich wüsste nicht, welche ich in diesem Fall vorschlagen sollte.