|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (4)
просмотр истории страницыФильтруются все пакеты, в ответ пользователю отправляется tcp-reset. |
{toc} |
|
Для редиректа необходима подмена сертификата, либо DNS, что не совсем приемлемо для большинства провайдеров и абонентов. |
Как фильтруется HTTPS? Вообще, способов фильтрации используется несколько и одновременно. У провайдера есть возможность включать/отключать способы так, как он считает нужным, рекомендации указаны при установке и в статье [http://carbonsoft.github.io/2016/11/10/i-installed-reductor-long-time-ago.html] Список подходов: * DNS фильтрация * SNI фильтрация * IP фильтрация * Проксирование HTTPS-трафика Фильтруются следующие порты: 443 в любом случае + все нестандартные порты у https-ссылок, имеющиеся в реестре. h2. DNS [http://docs.carbonsoft.ru/display/reductor5/DNS] h2. SNI Включена по умолчанию и крайне не рекомендуется к отключению. Используется в большей степени для подстраховки DNS-фильтрации, так как SNI-заголовок не обязателен в Client-Hello пакете. При срабатывании пользователю посылается TCP-RST пакет. *Принцип работы:* При запросе от абонентской машины IP адреса по доменному имени, редуктор отдаст "Ip адрес для DNS ответов" (из меню), на котором у вас находится страница заглушки. Если при этом использовалось https соединение, то опция SNI фильтрация исключит запрос и получение сертификата. FAQ: Q: Так ведь если сработает DNS-спуфинг, то SNI заблочит страницу заглушку. A: Ну да, такой баг был, но исправлен, трафик до страницы-заглушки DROP'ается в цепочке https_dst. Схема при срабатывании: {code} 1. Абонент ---TCP SYN--> Сервер 2. Абонент <--TCP SYN/ACK -- Сервер 3. Абонент ---TCP ACK--> Сервер 4. Абонент ---TCP: PSH/ACK SSL: Client Hello --> Сервер 5. Абонент <--TCP RST--- Редуктор .. x. Сервер ---TCP PSH/ACK SSL: Server Hello --> Абонент {code} Но абоненту будет уже не важно. h3. {color:#000000}{*}IP фильтрация{*}{color} Пользователь в итоге получает TCP-RST пакет. Состоит из трёх частей: h3. Фильтрация ресурсов, которые иначе не заблокировать например: {code} https://1.2.3.4/bad/things {code} При совпадении IP адресов, попавших в реестр в таком виде, пользователю посылается TCP-RST. h3. Фильтрация IP адресов всех HTTPS-ресурсов, имеющихся в реестре Не самая лучшая опция, но некоторым клиентам очень важна надёжность фильтрации, а эта опция её сильно повышает. h3. Фильтрация IP адресов из результатов резолва доменов, попавших для блокировки по домену или с https-ссылками. Используется резолвер, раз в пять минут обновляющий данные по часто меняющим IP адреса ресурсам. У него довольно сложное внутреннее устройство в плане структуры данных и модели принятия решения об их устаревании. Вкратце - он довольно таки небезопасен для использования, но в своё время (до появления DNS и SNI фильтрации) очень сильно спасал с фильтрацией HTTPS ресурсов, часто меняющих свой IP адрес. Списки фильтруемых в текущий момент IP можно посмотреть: {code} ipset save ip_https ipset save ip_https_plus {code} h2. Проксирование трафика Решение для редиректа и фильтрации с точностью до URL ресурсов, использующих технологию HSTS находится в экспериментальном состоянии. Большая часть популярных решений не обеспечивают должной производительности при потоке трафика больше 1гбит/c, а способы отправки трафика (BGP/OSPF) требуют знания всех IP адресов, в которые может отрезолвиться заблокированный ресурс на всех теоретически доступных DNS-серверах машин, проводящех проверку, что маловероятно является возможным. (будет 99% качество фильтрации и всегда будут пропуски). Пилотные проекты показывают переменный успех, необходимо больше тестирования на большой и реальной нагрузке. Непосредственно сейчас необходимости в этом нет. |