{toc}
Как фильтруется 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% качество фильтрации и всегда будут пропуски).
Пилотные проекты показывают переменный успех, необходимо больше тестирования на большой и реальной нагрузке.
Непосредственно сейчас необходимости в этом нет.
Как фильтруется 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% качество фильтрации и всегда будут пропуски).
Пилотные проекты показывают переменный успех, необходимо больше тестирования на большой и реальной нагрузке.
Непосредственно сейчас необходимости в этом нет.