Фильтрация HTTPS-контента и принудительное использование Captive Portal без MITM-прокси
Моя церковь хочет начать предоставлять бесплатный Wi-Fi для наших гостей, но с 2 требованиями:
- Неуместное содержание (например, порнография и Warez) должно быть отфильтровано.
- Конечный пользователь должен создать учетную запись и согласиться с нашими условиями (Captive Portal).
В настоящее время мы запускаем экземпляр Untangle с надстройками Web Filter, HTTPS Inspector и Captive Portal.
Это прекрасно работает с одним исключением: когда пользователь впервые подключается к нашему Wi-Fi, мы должны попросить его установить наш корневой сертификат CA, чтобы иметь возможность MITM-трафика HTTPS, чтобы отфильтровать плохой контент, или они получают подобное сообщение при попытке перейти на любой сайт через HTTPS:
Что является серьезным препятствием для входа, особенно для пользователей Internet Explorer, так как процесс импорта корневого сертификата может быть долгим и запутанным для неопытных людей.
У нас также есть несколько локальных компьютеров, которым нужен корневой сертификат, но мы можем развернуть его на тех, у кого есть объект групповой политики Active Directory, так что это не проблема.
Мы также рассмотрели следующие варианты:
Использование файла WPAD.DAT для отправки пользователей через наш фильтр: это кажется ненадежным (во многих браузерах он отключен по умолчанию).
Блокировка контента по IP: это означает поддержание черного списка IP, и конечный пользователь получает сообщение "отказано в соединении" вместо объяснения того, почему мы заблокировали этот контент.
Использование SNI для блокировки контента: Untangle поддерживает это сразу, но имеет ту же проблему, что и блокировка по IP (сообщение "соединение отказано").
Эта проблема также влияет на наш портал авторизации, так как нам нужно перенаправить пользователей на портал авторизации для входа в систему - что невозможно через HTTPS без MITM запроса / ответа.
Я что-то пропустил? Есть ли другой подход к решению этой проблемы, который проще для конечных пользователей / не требует от них ничего делать?
2 ответа
Рассмотрим вопрос, который вы задаете ("Как я могу обслуживать страницу блокировки вместо https://playboy.com/ без необходимости что-либо делать моим пользователям") как "Как я могу обслуживать свою собственную версию https://trusted-bank.com/ без ведома моих пользователей ".
HTTPS и браузеры (в наши дни) предназначены именно для этого. Это делает веб-фильтрацию сложной.
Даже если вы нажали на wpad и, таким образом, у вас есть явный прокси, вы все равно можете отказать только в подключении к "плохим" сайтам, хотя это действительно решает проблемы, связанные с sni, на самом деле это не продвинет вас намного дальше (с этим часть проблемы, как минимум).
С точки зрения обслуживания страницы входа, wispr полезен для информирования пользователя о необходимости входа в систему.
Поскольку это общедоступная организация, к которой вы обращаетесь, я чувствую, что вы не можете разумно просить их установить ваш корневой SSL-сертификат (как они узнают, что вы не сможете их потом исправить на своих домашних соединениях?). Процесс для этого также очень технический и зависит от браузера.
Я чувствую, что вы можете поддерживать черный список IP-адресов или полностью отключить соединения https. Для черного списка IP-да, они будут видеть только "отказ в соединении" вместо страницы ошибки пользовательской, но вам действительно нужно, чтобы объяснить, почему доступ к варезу или порнографии, был заблокирован? Отключение https означает, что люди не смогут заходить на некоторые конкретные веб-сайты - но подумайте, действительно ли людям нужен доступ к ним во время пребывания в церкви, или вы хотите, чтобы любой злоумышленник в ваши открытые сигналы Wi-Fi мог перехватывать свои соединения с ними, Возможно, чтобы компенсировать это, вы могли бы разрешить https (через ваш корневой сертификат и перехватывающий прокси-сервер) на компьютерах, принадлежащих церкви, в случае, если людям действительно нужно использовать эти сайты.
Вы можете настроить прозрачный прокси на вашем шлюзе. Например, в OpenWrt это можно сделать с помощью правил Tinyproxy и брандмауэра. Для SSL вам также понадобится перенаправитель с TCP на прокси, например, redsocks. Однако текущая версия redsocks использует HTTP 1.0 только для связи с прокси. Это предотвращает фильтрацию на стороне Tinyproxy (так как фильтрация основана на заголовке HTTP 1.1 Location). Но я верю, что вы можете найти альтернативу redsocks, которая поддерживает HTTP 1.1.
Также проверьте мою суть, с инструкциями и ссылками на другие соответствующие источники.