Просто интересно, полезен ли SNI для отделения публичного контента от частного. Мне удалось настроить наш сервер для обслуживания /foo
для каждого клиента, кроме обслуживания /bar
только для клиентов из интрасети, указав имя хоста, которое разрешается только из интрасети.
Итак, конфигурация выглядит примерно так: (без очень важной части)
NameVirtualHost *:443
# JkWorkersFile must be global so including it here
JkWorkersFile workers.properties
<VirtualHost *:443>
ServerName public.foo.com
JkMountFile uriworkermap-pub.properties
</VirtualHost>
<VirtualHost *:443>
ServerName private-foo
JkMountFile uriworkermap-priv.properties
</VirtualHost>
<VirtualHost *:443>
ServerName 10.1.2.3
JkMountFile uriworkermap-priv.properties
</VirtualHost>
Загвоздка в том, что если вы добавите это имя в свой hosts
файл для разрешения на общедоступный IP-адрес, тогда SNI фактически разрешит его обработку так же, как если бы это был действительный запрос из интрасети.
Я обыгрывал мысли об использовании только числовых IP вместо имен (например, 10.1.2.3
), но я предполагаю, что то же самое можно обмануть, если у клиента такой же IP-адрес в собственной подсети (например, хост Linux, который перенаправляет порты на общедоступный IP-адрес моего веб-сервера.
Узел находится за брандмауэром, на который я не могу повлиять. У него только один IP (внутренний), но при необходимости я могу сделать его два.
Практический вопрос: как предотвратить такую утечку? С помощью htaccess например? Указав разные IP-адреса? Или нет другого выхода, кроме как создать отдельный экземпляр сервера и забыть о SNI?
То, что вы пытаетесь сделать, называется «безопасностью через неясность» - вы на самом деле не обезопасили ресурс, вы просто надеетесь, что никто не узнает, как его искать, если только не изнутри вашей компании.
Кроме того, SNI не имеет отношения к этой проблеме. У вас была бы такая же проблема, если бы контент обслуживался через HTTP без сертификата вообще, и вы пытались заблокировать контент, скрывая его, используя отдельные имена хостов.
На самом деле это не безопасно.
Если вы хотите предварительно получить доступ к ресурсу, вам нужно сделать это другим способом. Один из способов - создать отдельный экземпляр сервера на отдельном IP-адресе и использовать брандмауэры для защиты этого экземпляра. Другой вариант - использовать блок на основе IP на виртуальном сервере, содержащем ограниченный контент, или в каталоге. Или вы можете объединить это с требованием от клиента использовать сертификат, выданный вашим внутренним центром сертификации, если он у вас есть. Или практически любой другой способ объединения аутентификации с авторизацией.
Но надежда на то, что никто за пределами вашей компании не попытается использовать «секретное» имя хоста, не является допустимой мерой безопасности, независимо от того, используете вы SSL / SNI или нет.
Если вам нужно ограничить контент на основе происхождения посетителей сайта, вы используете эту информацию в качестве основного элемента управления доступом (а не только имя ресурса, который вы пытаетесь защитить).
С Apache 2.2 это было бы Allow
Директива.
<VirtualHost *:443>
ServerName private-foo
<Location />
Order Deny,Allow
Deny from all
# Allow from the internal subnet 10.1.2.0/24
Allow from 10.1.2
</Location>
...
Часто в вашем сценарии сервер будет иметь внутренний и общедоступный IP-адрес, и поскольку внутренние пользователи будут использовать только этот внутренний IP-адрес, вы должны привязать виртуальный хост только к этому внутреннему IP-адресу, например. <VirtualHost 10.1.2.3:443>
вместо того, чтобы слушать все IP
Кроме того, ваше замечание относительно .htaccess вызвало у меня раздражение, цитируемое из руководство по .htaccess файлы:
Вам следует полностью избегать использования файлов .htaccess если у вас есть доступ к конфигурации главного сервера httpd файл. Использование файлов .htaccess замедляет работу вашего http-сервера Apache. Любую директиву, которую вы можете включить в файл .htaccess, лучше установить в
Directory
блок в основном файле (файлах) конфигурации Apache, так как он будет иметь тот же эффект с лучшей производительностью.