СЯУ: nginx и принудительный разрыв соединения
Сегодня я узнал что у nginx'а есть особый код возврата 444 который по факту принудительно разрывает соединение.
http://nginx.org/en/docs/http/request_processing.html#how_to_prevent_undefined_server_names
Прекрасно работает для http и в чем-то наверное самый правильный способ отвечать на запросы левых доменов:
server {
listen 80 default_server;
return 444; # Немедленный разрыв соединения
}
Однако для https оно в прямом виде не работает если вместо 80 поставить 443 ssl то оно без разговоров почему-то начинает рвать все https соединения, в том числе и те, для которых есть подобающий server_name в других разделах.
Если добавить туда информацию о каком-нибудь ключе и сертификате, то браузер сначала поругается на неверный сертификат, и если добавить его в исключения, то вот потом уже севрер разорвет соединение...
Ходят легенды, что в более новых nginx'ах есть переменная $ssl_server_name в из которой можно добыть имя домена прилетевшее в SNI при установке TLS соединения, и тогда можно учинить проверку вида
if ( $ssl_server_name = nataraj.su)
{
return 444;
}
см. https://serverfault.com/questions/325485/nginx-how-to-prevent-an-exactly-named-ssl-server-block-from-acting-as-the-catch/910419#910419
и https://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables
Но проверить мне это не удалось, потому что у меня боевой фронтенд nginx стар как моя жизнь, просто так его не обновишь, а городить отдельный огород чиста чтобы проверить мне лень...
Поэтому пусть будет непроверенной информацией...
Итого: того чего я хотел, а именно чтобы не обслуживаемые по https домены не обслуживались, я добился лишь частично. Нахрен шлют после добавления сертификата в исключения. Но есть надежда, что в светлом будущем это когда-нибудь получится...
Оригинал этой записи находится на https://nataraj.dreamwidth.org/979059.html. ( комментарии
) ( комментировать )
http://nginx.org/en/docs/http/request_processing.html#how_to_prevent_undefined_server_names
Прекрасно работает для http и в чем-то наверное самый правильный способ отвечать на запросы левых доменов:
server {
listen 80 default_server;
return 444; # Немедленный разрыв соединения
}
Однако для https оно в прямом виде не работает если вместо 80 поставить 443 ssl то оно без разговоров почему-то начинает рвать все https соединения, в том числе и те, для которых есть подобающий server_name в других разделах.
Если добавить туда информацию о каком-нибудь ключе и сертификате, то браузер сначала поругается на неверный сертификат, и если добавить его в исключения, то вот потом уже севрер разорвет соединение...
Ходят легенды, что в более новых nginx'ах есть переменная $ssl_server_name в из которой можно добыть имя домена прилетевшее в SNI при установке TLS соединения, и тогда можно учинить проверку вида
if ( $ssl_server_name = nataraj.su)
{
return 444;
}
см. https://serverfault.com/questions/325485/nginx-how-to-prevent-an-exactly-named-ssl-server-block-from-acting-as-the-catch/910419#910419
и https://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables
Но проверить мне это не удалось, потому что у меня боевой фронтенд nginx стар как моя жизнь, просто так его не обновишь, а городить отдельный огород чиста чтобы проверить мне лень...
Поэтому пусть будет непроверенной информацией...
Итого: того чего я хотел, а именно чтобы не обслуживаемые по https домены не обслуживались, я добился лишь частично. Нахрен шлют после добавления сертификата в исключения. Но есть надежда, что в светлом будущем это когда-нибудь получится...
Оригинал этой записи находится на https://nataraj.dreamwidth.org/979059.html. ( комментарии
) ( комментировать )