Назад | Перейти на главную страницу

Проблемы безопасности SSL SNI

Просто интересно, полезен ли 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, так как он будет иметь тот же эффект с лучшей производительностью.