Конфликт между доменами, предоставленными SNI и HTTP


22

Недавно я переместил веб-сайт WordPress с небольшим магазином с хостинг-провайдера на сервер собственного Ubuntu Server 12.04.2 LTS и Apache 2.2.22. Мне требуется SSL для магазина. Я установил пару простых vhosts на новый IP-адрес для сервера, одну привязку к порту 80 определенного IP, а другую привязку к порту 443. Оба они имеют ServerName www.example.comи ServerAlias example.comв конфигурации vhost. У меня есть SSLStrictSNIVHostCheck off.

Сайт работает очень медленно, но работает. Я получаю следующее в моих журналах ошибок.

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

Я ожидаю, что медлительность связана с приведенным выше сообщением. Любые идеи о том, почему это появляется и что я могу с этим поделать?

Ответы:


24

Посмотрите на ваш журнал доступа (не журнал ошибок). Со временем и датой ошибки вы сможете идентифицировать оскорбительный запрос и найти пользовательский агент. В моем случае это был бот:

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

Мой сервер отвечает с HTTP 400: неверный запрос.

Если я не ошибаюсь, при согласовании TLS клиент отправляет имя хоста дважды: один раз ДО установления соединения SSL в SNI (индикация имени сервера) и один раз ПОСЛЕ в фактическом HTTP-запросе. Если имена серверов не совпадают, это будет указывать на неисправный клиент и не должно иметь никакого отношения к настройке вашего сервера.

Возможно, они когда-нибудь починят своего бота, а тем временем вы можете его проигнорировать. Я сомневаюсь, что это может вызвать медлительность на хосте, если запросы не приходят с очень высокой скоростью.


11

Возможно, эта ошибка намеренно вызывается некоторыми клиентами для проверки уязвимостей вашего сервера. Я обнаружил, что запрос researchscan367.eecs.umich.eduсгенерировал ошибку на сервере, который я обслуживаю. В этом случае хорошо, что произошла ошибка.

Мне было любопытно, какие виды атак возможны, и я задал этот вопрос на бирже стеков безопасности: какую атаку предотвращает код ошибки Apache2 AH02032?


1

На первый взгляд, похоже на проблему с клиентом ... Какой браузер вызывает эту проблему?

В сообщении указывалось бы, что имя хоста, которое клиент отправляет во время настройки соединения ssl, не совпадает с тем, которое клиент отправляет в запросе HTTPS, когда уровень SSL установлен.


Я не знаю, что вызывает это. Ошибка не сообщает информацию о клиенте. Я просто знаю, что вижу это регулярно. Я надеялся, что ServerAlias ​​было достаточно, чтобы сделать его счастливым, поскольку теоретически сервер знает, что www.domain.com и domain.com эквивалентны.
мерцание

@flickerfly Да, это клиент с ошибками, и вы мало что можете сделать, если не сможете его идентифицировать.
Майкл Хэмптон

2
Ладно, просто отключил SNI, удалив директиву NameBasedVirtualHost для порта 443. Полагаю, он мне сейчас не нужен. Я думаю, что это должно сработать.
flickerfly

1

В моем случае проблема была в создании нового виртуального хоста с подчеркиванием. У меня есть сертификат SSL подстановочного знака.

Не работал:

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

Хотя Apache успешно перезапустился, я получил ошибки HTTP 400. В журнале ошибок:

[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

Но снятие подчеркивания сработало:

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

1
Добро пожаловать в ServerFault. Вставка подчеркивания в имена хостов противоречит RFC и будет ломаться разными способами. stackoverflow.com/questions/2180465/…
цыплята

1
В точку! Вот почему это теперь также здесь в качестве ссылки.
MS Berends

0

Проверьте файл / etc / hosts, чтобы узнать, назначаете ли вы имя домена для локального (внутреннего) IP-адреса. Не забудьте перезапустить демон кэша службы имен после изменения / etc / hosts service nscd restart

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.