Konflikt zwischen von SNI und HTTP bereitgestellten Domänen

Konflikt zwischen von SNI und HTTP bereitgestellten Domänen

Ich habe vor Kurzem eine WordPress-Website mit einem kleinen Shop von einem Hosting-Anbieter auf einen eigenen Server verschoben, auf dem Ubuntu Server 12.04.2 LTS und Apache 2.2.22 laufen. Ich benötige SSL für den Shop. Ich habe ein paar einfache virtuelle Hosts auf einer neuen IP für den Server eingerichtet, einen mit Bindung an Port 80 der spezifischen IP und den anderen mit Bindung an Port 443. Beide haben ServerName www.example.comund ServerAlias example.comin der virtuellen Host-Konfiguration. Ich habe SSLStrictSNIVHostCheck off.

Die Site läuft sehr langsam, funktioniert aber. In meinen Fehlerprotokollen wird Folgendes angezeigt.

[Error] Hostname example.com provided via SNI and hostname www.example.com provided via HTTP are different

Ich vermute, dass die Verlangsamung mit der obigen Meldung zusammenhängt. Irgendwelche Ideen, warum diese Meldung erscheint und was ich dagegen tun kann?

Antwort1

Sehen Sie sich Ihr Zugriffsprotokoll an (nicht das Fehlerprotokoll). Anhand der Uhrzeit und des Datums des Fehlers sollten Sie in der Lage sein, die fehlerhafte Anfrage zu identifizieren und den Benutzeragenten herauszufinden. In meinem Fall war es ein Bot:

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2)"

Mein Server antwortet mit HTTP 400: Ungültige Anfrage.

Wenn ich mich nicht irre, sendet der Client bei TLS-Verhandlungen den Hostnamen zweimal: einmal VOR dem Aufbau der SSL-Verbindung in der SNI (Server Name Indication) und einmal DANACH in der eigentlichen HTTP-Anforderung. Wenn die Servernamen nicht übereinstimmen, deutet dies auf einen defekten Client hin und sollte nichts mit der Konfiguration Ihres Servers zu tun haben.

Vielleicht reparieren sie ihren Bot irgendwann, in der Zwischenzeit können Sie ihn wahrscheinlich ignorieren. Ich bezweifle, dass dies zu einer Verlangsamung des Hosts führen kann, es sei denn, die Anfragen kommen mit einer sehr hohen Rate.

Antwort2

Vielleicht wird dieser Fehler hervorgerufenabsichtlichvon einigen Clients, um Schwachstellen Ihres Servers zu testen. Ich habe festgestellt, dass eine Anfrage von researchscan367.eecs.umich.eduden Fehler auf einem von mir betreuten Server auslöste. In diesem Fall ist es eine gute Sache®, dass der Fehler auftritt.

Ich war neugierig, welche Arten von Angriffen möglich sind, und habe diese Frage auf Security Stack Exchange gestellt:Welche Art von Angriff wird durch den Apache2-Fehlercode AH02032 verhindert?

Antwort3

In meinem Fall war die Erstellung eines neuen virtuellen Hosts mit einem Unterstrich das Problem. Ich habe ein Wildcard-SSL-Zertifikat.

Hat nicht funktioniert:

<VirtualHost *:443>
        SSLEngine on
        ServerName sub_domain.example.com
        Redirect / https://www.example.com/restofmyredirectlink
</VirtualHost>

Obwohl Apache erfolgreich neu gestartet wurde, erhielt ich HTTP 400-Fehler. Im Fehlerprotokoll:

[Wed Sep 05 11:28:00.349960 2018] [ssl:error] [pid 19906:tid 140392626808576] AH02031: Hostname sub_domain.example.com provided via SNI, but no hostname provided in HTTP request

Aber das Entfernen des Unterstrichs hat funktioniert:

<VirtualHost *:443>
        SSLEngine on
        ServerName subdomain.example.com
        Redirect / https://www.example.com/restofmyredirectlink
</VirtualHost>

Antwort4

Überprüfen Sie Ihre /etc/hosts-Datei, um zu sehen, ob Sie den Domänennamen einer lokalen (internen) IP-Adresse zuweisen. Vergessen Sie nicht, den Name Service Cache Daemon nach der Änderung von /etc/hosts service nscd restart neu zu starten.

verwandte Informationen