Konflikt zwischen von SNI und HTTP bereitgestellten Domänen

22

Ich habe kürzlich eine WordPress-Website mit einem kleinen Laden von einem Hosting-Anbieter auf einen eigenen Server mit Ubuntu Server 12.04.2 LTS und Apache 2.2.22 verschoben. Ich benötige SSL für den Shop. Ich habe ein paar einfache vhosts auf einer neuen IP für den Server eingerichtet, eine Bindung an Port 80 der spezifischen IP und die andere Bindung an Port 443. Beide haben ServerName www.example.comund ServerAlias example.comin der vhost-Konfiguration. Ich habe SSLStrictSNIVHostCheck off.

Die Seite 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 gehe davon aus, dass die Langsamkeit mit der obigen Meldung zusammenhängt. Irgendwelche Ideen, warum das auftaucht und was ich dagegen tun kann?

apache-2.2 virtualhost

— Flackerfliege
quelle

24

Sehen Sie sich Ihr Zugriffsprotokoll an (nicht das Fehlerprotokoll). Mit der Uhrzeit und dem Datum des Fehlers sollten Sie in der Lage sein, die störende Anforderung 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: Bad Request.

Wenn ich mich nicht irre, sendet der Client bei TLS-Verhandlungen den Hostnamen zweimal: einmal, BEVOR die SSL-Verbindung im SNI (Server Name Indication) hergestellt wird, und einmal, NACHDEM in der eigentlichen HTTP-Anforderung. Wenn die Servernamen nicht übereinstimmen, weist dies auf einen fehlerhaften Client hin und sollte nichts mit der Konfiguration Ihres Servers zu tun haben.

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

— Arno Schäfer
quelle

11

Möglicherweise wird dieser Fehler von einigen Clients absichtlich ausgelöst, um die Schwachstellen Ihres Servers zu testen. Ich habe festgestellt, dass eine Anfrage von researchscan367.eecs.umich.eduden Fehler auf einem Server ausgelöst, den ich pflege. In diesem Fall ist es gut, dass der Fehler auftritt.

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

— jknappen - Setzen Sie Monica wieder ein
quelle

1

Klingt auf den ersten Blick nach einem Client-Problem ... Welcher Browser verursacht dieses Problem?

Die Nachricht schlägt vor, dass der Hostname, den der Client während des SSL-Verbindungsaufbaus sendet, nicht derselbe ist, den der Client in der HTTPS-Anforderung sendet, sobald die SSL-Schicht aktiv ist.

— alxgomz
quelle

Ich weiß nicht, was das verursacht. Der Fehler meldet keine Clientinformationen. Ich weiß nur, dass ich das regelmäßig sehe. Ich hatte gehofft, dass die ServerAlias ausreichen, um es glücklich zu machen, da der Server theoretisch weiß, dass www.domain.com und domain.com gleichwertig sind.

— Flickerfly

@flickerfly Ja, dies ist ein fehlerhafter Client, und Sie können nur viel tun, wenn Sie ihn identifizieren können.

— Michael Hampton

2

Okay, SNI wurde einfach deaktiviert, indem die Direktive NameBasedVirtualHost für Port 443 entfernt wurde. Ich glaube, ich brauche sie zu diesem Zeitpunkt nicht. Ich denke, das sollte funktionieren.

— Flickerfly

1

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, wurden HTTP 400-Fehler gemeldet. 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>

— MS Berends
quelle

1

Willkommen bei ServerFault. Das Setzen von Unterstrichen in Hostnamen ist gegen die RFCs und wird auf verschiedene Arten unterbrochen. stackoverflow.com/questions/2180465/…

— chicks

1

Genau! Deshalb ist es jetzt auch hier als Referenz.

— MS Berends

0

Überprüfen Sie in Ihrer Datei / etc / hosts, ob Sie den Domänennamen einer lokalen (internen) IP-Adresse zuweisen. Vergessen Sie nicht, den Nameservice-Cache-Daemon nach dem Ändern von / etc / hosts service nscd restart neu zu starten

— Jim Da Otter
quelle