Ещё немного про роскомнадзор и https

Второго декабря Россия лишилась доступа к GitHub по решению Роспотребнадзора. Информация с разъяснением причин блокировки для широкой общественности выглядит так:

Для узких кругов есть ещё вот такая информация:

скриншот с rublacklist

Все заблокированные страницы содержат копию какого-то пародийного (и местами смешного) текста, описывающего способы себяцида (простите за это слово, боюсь за хабр).

Проблема

В реестр внесено всего семь страниц. В интернете есть много обсуждений, почему из-за семи копий текста заблокирован весь ресурс, ведь закон требует ограничивать доступ именно к отдельным страницам. Результаты обсуждений сводятся к тому, что плохие провайдеры поскупились на DPI, поэтому банят сайты по IP.

Банить, конечно, можно разными способами: чёрные списки по IP на роутерах, подмена записей в DNS, проксирование трафика, ну и, конечно, DPI, от которого требуется инспектировать только http-заголовки. Во всех случаях, кроме последнего, заблокировать отдельную страницу сайта невозможно. Крупные провайдеры используют последний вариант, но есть нюанс.

Https-трафик — зашифрован. DPI сможет узнать максимум имя домена, к которому был сделан запрос, потому что строка GET в http-заголовке — зашифрована (весь заголовок зашифрован, весь запрос зашифрован). Без DPI провайдер имеет информацию только об IP-адресе.

Это значит, что постраничная блокировка для https-ресурса невозможна. Именно в этом причина, по которой даже «хорошие» провайдеры заблокировали GitHub полностью.

Варианты

Конечно, есть варианты. Можно административно запретить добавление https-ресурсов в Реестр. Можно игнорировать https-ресурсы, которые в Реестр всё-таки попадают. Либо, можно найти техническое решение.

Чтобы блокировать https-ресурсы постранично, пользователю придётся согласиться на схему MITM, провайдеру придётся подделывать сертификат блокируемого ресурса и расшифровывать все https-запросы. Ну, может не все, а только если IP-адрес сервера входит в список Роскомнадзора. При чём не только расшифровывать, но и выступать в роли прокси. К тому же, если провайдер не располагает сертификатом, который установлен у клиента в качестве доверенного, то браузер пользователя будет постоянно ругаться на поддельный сертификат. А чтобы не ругался — придётся внедрять свой сертификат в браузер пользователя.

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

Поэтому постраничная блокировка на https-ресурсов так и останется невозможной, а GitHub и подобные ресурсы будут баниться полностью по IP из-за одного любого документа.

Выводы

Теперь вы знаете, почему youtube не использует https [по умолчанию].