Conflit entre les domaines fournis par SNI et HTTP

22

J'ai récemment déplacé un site Web WordPress avec une petite boutique d'un fournisseur d'hébergement vers un serveur de mon propre exécutant Ubuntu Server 12.04.2 LTS et Apache 2.2.22. J'ai besoin de SSL pour le magasin. J'ai installé quelques vhosts simples sur une nouvelle IP pour le serveur, une liaison au port 80 de l'IP spécifique et l'autre liaison au port 443. Les deux ont ServerName www.example.comet ServerAlias example.comdans la configuration vhost. Je l'ai SSLStrictSNIVHostCheck off.

Le site fonctionne très lentement, mais fonctionne. J'obtiens ce qui suit dans mes journaux d'erreurs.

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

Je m'attends à ce que la lenteur soit liée au message ci-dessus. Avez-vous des idées sur pourquoi cela apparaît et ce que je peux faire à ce sujet?

apache-2.2 virtualhost

— flickerfly
source

24

Regardez votre journal d'accès (pas le journal des erreurs). Avec l'heure et la date de l'erreur, vous devriez être en mesure d'identifier la demande incriminée et de trouver l'agent utilisateur. Dans mon cas, c'était un bot:

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

Mon serveur répond avec HTTP 400: Bad Request.

Sauf erreur, dans les négociations TLS, le client envoie le nom d'hôte deux fois: une fois AVANT que la connexion SSL soit établie dans le SNI (Server Name Indication) et une fois APRÈS dans la requête HTTP réelle. Si les noms de serveur ne correspondent pas, cela indiquerait un client défectueux et ne devrait rien avoir à voir avec la configuration de votre serveur.

Peut-être qu'ils répareront leur bot un jour, en attendant, vous pouvez probablement l'ignorer. Je doute que cela puisse entraîner une lenteur sur l'hôte, sauf si les demandes arrivent à un rythme très élevé.

— Arno Schäfer
source

11

Peut-être que cette erreur est évoquée intentionnellement par certains clients pour tester les vulnérabilités de votre serveur. J'ai constaté qu'une demande de a researchscan367.eecs.umich.edudéclenché l'erreur sur un serveur que je gère. Dans ce cas, c'est une bonne chose que l'erreur se produise.

J'étais curieux de savoir quels types d'attaques sont possibles, et j'ai posé cette question sur Security Stack Exchange: quel type d'attaque est empêché par le code d'erreur AH02032 d'Apache2?

— jknappen - Réintégrer Monica
source

1

Cela ressemble à un problème client à première vue ... Quel navigateur est à l'origine de ce problème?

Le message suggérerait que le nom d'hôte que le client envoie lors de la connexion SSL n'est pas le même que celui envoyé par le client dans la demande HTTPS une fois la couche SSL en place.

— alxgomz
source

Je ne sais pas ce qui cause ça. L'erreur ne signale pas les informations client. Je sais juste que je vois ça régulièrement. J'espérais que le ServerAlias était suffisant pour le rendre heureux car en théorie le serveur sait que www.domain.com et domain.com sont équivalents.

— flickerfly

@flickerfly Oui, c'est un client buggy, et vous ne pouvez pas faire grand chose à moins de pouvoir l'identifier.

— Michael Hampton

2

D'accord, juste désactivé SNI en supprimant la directive NameBasedVirtualHost pour le port 443. Je suppose que je n'en ai pas besoin à ce stade. Je pense que c'est censé fonctionner.

— flickerfly

1

Dans mon cas, la création d'un nouvel hôte virtuel avec un trait de soulignement était le problème. J'ai un certificat SSL générique.

N'a pas fonctionné:

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

Bien qu'Apache ait redémarré avec succès, j'ai eu des erreurs HTTP 400. Dans le journal des erreurs:

[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

Mais la suppression du trait de soulignement a fonctionné:

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

— MS Berends
source

1

Bienvenue sur ServerFault. Mettre des traits de soulignement dans les noms d'hôtes est contraire aux RFC et se brisera de diverses manières. stackoverflow.com/questions/2180465/…

— poussins

1

Exactement! C'est pourquoi il est maintenant également ici comme référence.

— MS Berends du

0

Vérifiez votre fichier / etc / hosts pour voir si vous attribuez le nom de domaine à une adresse IP locale (interne). N'oubliez pas de redémarrer le démon de cache du service de noms après avoir modifié / etc / hosts service nscd restart

— Jim Da Otter
source