Фильтрация содержимого HTTPS и принудительное использование Captive Portal без прокси-сервера MITM

Моя церковь хочет начать предоставлять нашим гостям бесплатный Wi-Fi, но с двумя требованиями:

Неуместное содержание (например, порнография и Warez) должно быть отфильтровано.
Конечный пользователь должен создать учетную запись и согласиться с нашими условиями (Captive Portal).

В настоящее время мы запускаем экземпляр Распутать с Веб-фильтр, Инспектор HTTPS и Портал захвата дополнения.

Это отлично работает, за одним исключением: когда пользователь впервые подключается к нашему Wi-Fi, мы должны попросить его установите наш корневой сертификат CA чтобы иметь возможность MITM своего HTTPS-трафика для фильтрации плохого контента, иначе они получат подобное сообщение при попытке перейти на любой сайт по HTTPS:

Что является серьезным препятствием для входа, особенно для пользователей Internet Explorer, поскольку процесс импорта корневого сертификата может быть долгим и запутанным для нетехнических людей.

У нас также есть несколько локальных компьютеров, которым нужен корневой сертификат, но мы можем развернуть его на тех, у кого есть объект групповой политики Active Directory, так что это не проблема.

Мы также рассмотрели следующие варианты:

Используя Файл WPAD.DAT для отправки пользователей через наш фильтр: это кажется ненадежным (во многих браузерах он отключен по умолчанию).
Блокировка контента по IP: это означает ведение черного списка IP-адресов, и конечный пользователь получает сообщение «В соединении отказано» вместо объяснения того, почему мы заблокировали этот контент.
С помощью SNI чтобы заблокировать контент: Untangle поддерживает это из коробки, но имеет ту же проблему, что и блокировка по IP (сообщение «соединение отклонено»).

Эта проблема также влияет на наш администрирующий портал, поскольку нам необходимо перенаправить пользователей на администрирующий портал для входа в систему, что невозможно по HTTPS без MITM запроса / ответа.

Я что-то упускаю? Есть ли другой подход к решению этой проблемы, более простой для конечного пользователя / не требующий от них делать что-нибудь?

Обдумайте вопрос, который вы задаете ("Как я могу показывать заблокированную страницу вместо 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.

Также проверьте мои суть, с инструкциями и ссылками на другие соответствующие источники.