Konflikt między domenami SNI i HTTP

22

Niedawno przeniosłem witrynę WordPress z małym sklepem od dostawcy hostingu na serwer mojego własnego Ubuntu Server 12.04.2 LTS i Apache 2.2.22. Potrzebuję SSL do sklepu. Założyłem parę prostych vhostów na nowym IP serwera, jedno wiązanie z portu 80 na konkretnych IP i inne wiązanie z portu 443. Oba mają ServerName www.example.comi ServerAlias example.comw config vhost. Mam SSLStrictSNIVHostCheck off.

Strona działa bardzo wolno, ale działa. Otrzymuję następujące informacje w moich dziennikach błędów.

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

Oczekuję, że powolność jest związana z powyższym komunikatem. Wszelkie pomysły na to, dlaczego to się pojawia i co mogę z tym zrobić?

apache-2.2 virtualhost

— Flickerfly
źródło

24

Przejrzyj dziennik dostępu (nie dziennik błędów). Z czasem i datą błędu powinieneś być w stanie zidentyfikować niepoprawne żądanie i znaleźć klienta użytkownika. W moim przypadku był to bot:

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

Mój serwer odpowiada za pomocą HTTP 400: złe żądanie.

O ile się nie mylę, w negocjacjach TLS klient wysyła nazwę hosta dwukrotnie: raz PRZED nawiązaniem połączenia SSL w SNI (Wskazanie nazwy serwera) i raz PO rzeczywistym żądaniu HTTP. Jeśli niedopasowane są nazwy serwerów, oznaczałoby to uszkodzenie klienta i nie powinno mieć nic wspólnego z konfiguracją serwera.

Może kiedyś naprawią swojego bota, tymczasem prawdopodobnie możesz go zignorować. Wątpię, czy może to spowodować spowolnienie na hoście, chyba że żądania przychodzą bardzo szybko.

— Arno Schäfer
źródło

11

Być może ten błąd jest celowo wywoływany przez niektórych klientów w celu przetestowania podatności twojego serwera. Zauważyłem, że żądanie researchscan367.eecs.umich.eduwywołało błąd na serwerze, który utrzymuję. W tym przypadku dobrze jest, że błąd występuje.

Byłem ciekawy, jakie rodzaje ataków są możliwe, i zadałem to pytanie na Security Stack Exchange: Jakiemu atakowi zapobiega kod błędu AH02032 Apache2?

— jknappen - Przywróć Monikę
źródło

1

Na pierwszy rzut oka wygląda to na problem klienta ... Jaka przeglądarka powoduje ten problem?

Komunikat sugeruje, że nazwa hosta, którą klient wysyła podczas konfiguracji połączenia ssl, nie jest taka sama, jak klient wysyła żądanie HTTPS, gdy warstwa SSL zostanie uruchomiona.

— alxgomz
źródło

Nie wiem co to powoduje. Błąd nie zgłasza informacji o kliencie. Wiem tylko, że widzę to regularnie. Miałem nadzieję, że ServerAlias wystarczy, by go uszczęśliwić, ponieważ teoretycznie serwer wie, że www.domain.com i domain.com są równoważne.

— flickerfly

@flickerfly Tak, to jest błędny klient i niewiele można zrobić, chyba że można go zidentyfikować.

— Michael Hampton

2

Ok, właśnie wyłączyłem SNI, usuwając dyrektywę NameBasedVirtualHost dla portu 443. Wydaje mi się, że nie potrzebuję go w tym momencie. Myślę, że to powinno zadziałać.

— flickerfly

1

W moim przypadku problemem było utworzenie nowego hosta wirtualnego z podkreśleniem. Mam wieloznaczny certyfikat SSL.

Nie działał:

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

Chociaż Apache zrestartował się pomyślnie, dostałem błędy HTTP 400. W dzienniku błędów:

[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

Ale usunięcie podkreślenia zadziałało:

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

— MS Berends
źródło

1

Witamy w ServerFault. Umieszczanie znaków podkreślenia w nazwach hostów jest sprzeczne z RFC i psuje się na różne sposoby. stackoverflow.com/questions/2180465/…

— pisklęta

1

Dokładnie! Dlatego właśnie teraz jest tutaj również jako odniesienie.

— MS Berends,

0

Sprawdź plik / etc / hosts, aby sprawdzić, czy przypisujesz nazwę domeny do lokalnego (wewnętrznego) adresu IP. Nie zapomnij zrestartować demona pamięci podręcznej usługi nazw po zmianie / etc / hosts service nscd restart

— Jim Da Otter
źródło