как не странно это не чисто русское слово и даже не VPN. но что же тогда это такое? вот эти загадочные буквы ECH. ну и что же обозначают эти буквы и почему РКН действительно видит в них угрозу? в интернете много информации по ECH, но почему они вызывают такое оживление? я сам не раз упоминал эту технологию. но не было отдельной заметки. давайте остановимся на ней чуть подробнее, я постараюсь сделать заметку интересную профессионалам так людям не имеющим отношения к сетевой инженерии, но начать продеться из далека.
начнём с OSI
(Open Systems Interconnection) — это модель разработанная для описания взаимодействия устройств в компьютерных сетях. для чего вообще это понадобилось? ну было бы странно если бы ваш браузер интересовался как вы передаёте информацию по оптическому волокну, по радиоканалу или по медному проводу. т.е. нужны некие уровни абстракции.
например есть некая среда в которой имет смысл говорить о физических принципах, но есть некий другой выше лежащий уровень который передаёт данные. он ничего не знает о физике вашего канального уровня он просто пересылает пакет данных внутри вашего физического уровня. ему просто говорят: "отправь это от меня кому-то." есть ещё выше уровень который связывает воедино физически разные сегменты и так далее вплоть до кнопки "позвонить жене". в модели OSI выделяют 7 уровней:
- Физический уровень (L1). отвечает за передачу сигналов. фактически "уровень провода", уровень физических принципов передачи сигнала.
- Канальный уровень (L2). выполняет функции передачи данных над физическим уровнем. т.е. абстракция от методов передачи данных, есть сетевые адреса, но данные предаются внутри одного физического сегмента.
- Сетевой уровень (L3). объединяет сегменты, понятие сетевого узла и его адреса
- Транспортный уровень (L4). протоколы передачи данных между узлами
- Сеансовый уровень (L5). уровень взаимодействия между узлами.
- Уровень представления (L6). информация представляется в виде пригодном для передачи.
- Прикладной уровень (L7). взаимодействие пользовательских приложений с сетью.
в качестве протокола L3 как правило выступает TCP/IP. сейчас это в основном IPv4 (IP версия 4)активно вытесняемый IPv6. IP (Internet Protocol) неточно соответствует модели OSI, однако обычно используются именно понятия OSI чтобы можно было легко, а главное всегда одинакого, обозначить предмет обсуждения. ну а теперь можно поговорить
о методах шифрования.
вообще говоря ничто не мешает придумать свои методы шифрования, но рассмотрим стандартные. не будем рассматривать алгоритмы это в большей степени удел математиков. нам важен уровень OSI на котором происходит шифрование.
- IP-security (IPsec) этот метод шифрует соединение на сетевом уровне (L3), мы его рассматривать не будем.
- TLS (Transport Layer Security) стандартный протокол для установки защищённого соединения, работает на транспортном уровне (L4).
почему кстати соединение защищённое, а не просто шифрованное? потому что кроме шифрования, которые делает данные недоступные 3-тей стороне, проверяется ещё и аутентичность т.е. подлинность узла с которым вы устанавливаете соединение. в TLS используется понятие SNI (Server Name Indication) которое и идентифицирует узел с которым вы устанавливаете соединение.
вы набираете в браузере https://www.youtube.com . браузер понимает что вы хотите использовать протокол httpS который является версией протокола http использующий безопасное соединение. как я уже говорил для установки защищённого соединения современный браузер будет использовать протокол TLS.
браузер начинает устанавливать соединение. естественно ему первым делом надо передать SNI т.е. имя сайта к которому ему нужно обратиться. казалось бы зачем нам этот шаг? ведь можно сразу устанавливать шифрованное соединение. но к сожалению жизнь сложнее. часто бывает так, что на одном сетевом адресе может быть несколько SNI. для данного примера несколько сайтов на одном сетевом адресе.
т.е. если бы всегда на одном сетевом адресе размешался один сайт этот шаг можно было бы пропустить. после ответа сервера и проверки браузером его подлинности, если подлинность подтверждается, то происходит обмен симметричными ключами и устанавливается защищённое соединение, в противном случае браузер выбросит ошибку о том, что не может подтвердить подлинность ресурса.
вы проблему видите? а она как тот самый суслик есть. да передача SNI осуществляется ДО установки защищённого соединения. при чем получается порочный круг. нам нужно знать что можно доверять этому SNI до проверки его подлинности. хотя кто-то наверно скажет что это не принципиально: ну установили соединение не пойми с кем, начали проверять подлинность - Федот да не тот, ну разорвали соединение ничего страшного. я в общем то придерживаюсь такой же точки зрения, но не я TLS разрабатывал. ну и как нам выйти из это ситуации? не мудрствуя лукаво решение разработчиками TLS было принято в лоб:
SNI до версии TLS 1.3 передаётся в открытом виде.
как не трудно догадаться именно эти данные используются РКН для блокировки. пакет содержащий SNI называется TLS Client Hello. DPI тупо ищет в этом пакете строку соответствующую нужному SNI если такая строка находится, то такой пакет отбрасывается. для ютуб такая строка "googlevideo.com" - фактически имя домена.
ECH
(Encrypted Client Hello) — это расширение протокола TLS 1.3 которое позволяет шифровать TLS Client Hello полностью. как нетрудно догадаться нет данных по которым можно осуществлять блокировку и поэтому РКН блокирует большинство сайтов использующие это протокол за зоной их ответственности.
сейчас модно использовать (Content Delivery Network, «сеть доставки контента») это некоторое количество узлов разбросанных по всему интернету и как правило вы получаете контент с ближайшего к вам узла, где это контент закеширован. т.е. вы набираете https://www.youtube.com, начинаете смотреть видео https://www.youtube.com/watch?v=4iAkAT7mhnw
но видео вы получаете с ближайшего узла имеющим имя некий_хост.googlevideo.com .
в этом кстати конфликт РКН и СloudFlare. CDN СloudFlare использует ECH поэтому там размещаются многие "заблокированные" в Росси сайты. сделать что-то кардинальное с СloudFlarе в РКН попытались, но эти неуклюжие попытки закончились ничем. и РКН ограничилась "типа блокировкой" по SNI.
как работает ECH.
во-первых например в FireFox с настройками по умолчанию ЕСH не будет работать без DoH. про DoH я писал. в конце концов если ничего не поможет прочтите документацию к браузеру.
алгоритмы используемые ECH.
- в DNS распространяется открытый долговременный асимметричный ключ. напомню, что асимметричное шифрование это такое шифрование при котором зашифровать данные может кто угодно открытым ключом, а расшифровать только тот у кого есть приватный ключ.
- далее клиент придумывает симметричный ключ - этот ключ одинаковый для клиента и сервера. шифрование симметричными ключами намного мене затратно сточки зрения вычислительных ресурсов. при этом ключ передаётся не в открытом виде, а шифруется публичным ключом и передаётся серверу.
это делается для того чтобы передавать серверу каждый раз разные данные, что делает невозможной блокировку. ведь какая разница какие данные блокировать шифрованные или открытые - главное что выглядят всегда одинаково. а если данные каждый раз разные, то их выделить затруднительно, кроме того обеспечивается эфемерность т.е. данные актуальны только для конкретного сеанса связи (безопасность в будущем).
кроме всего прочего такая передача обеспечивает ещё и проверку аутентичности. т.е. информацию можно извлечь только приватным ключом. считается что публичный ключ распространил владелец приватного ключа. т.е. смысла распространять публичный ключ не имея приватного нет никакого, только если ключ так или иначе был скомпрометирован. впрочем подлинность проверяется ещё раз "обычным" способом.
после обмена ключами по предварительно защищённому каналу связи передаётся TLS Client Hello. по этому технология получила название Encrypted Client Hello.
однако как я уже сказал эту технологию по понятным причинам РКН пытается блокировать. метод обхода такой "блокировки" очень простой. я говорил о нем в статье про ютуб не хочу привлекать лишнее внимание позорного ведомства. скажу только что политика некой программы входящий в состав некого пакета будет ещё проще:
--dpi-desync=split2
--dpi-desync-split-seqovl=652
--dpi-desync-split-pos=2
--dpi-desync-split-seqovl-pattern="/var/zapret_fake/rnd.bin
т.е. нам даже не нужен мультисплит хватит одной позиции резки 2
хочу только дополнительно обратить внимание, что поддержка данной технологии требуется ещё на стороне сервера. например ютуб данную технологию не использует, а использует например кинозал и рутракер. вернее использует CDN Claudflare. хотя ввиду криворукости РКН даже такая политика будет работать с большинством сайтов. стоит правда отметить что метод может ломать сайты на поделке от майкрософт, но к счастью таких сайтов очень мало. единственный мне известный - госуслуги.
сам я использую своё классическое решение с 4 местами резки - шинкует "googlevideo.com" в капусту:
--dpi-desync=multisplit
--dpi-desync-split-seqovl=652
--dpi-desync-split-seqovl-pattern="/var/zapret_fake/rnd.bin"
--dpi-desync-split-pos=2,sld-1,endsld-5,endsld
решает большинство ваших проблем. --dpi-desync-split-seqovl-pattern="/var/zapret_fake/rnd.bin - это файл шаблон который используется для заполнения мест резки. сделайте файлик забив его случайными цифрами, либо укажите путь/имя файла которым можно использовать как шаблоном - можно тупо ткнуть в любую фотографию небольшого размера.
правда надо отметить, что такое решение ломает виндовые сайты, к счастью таких сайтов немного. кроме госуслуг других сайтов не знаю. есть смысл забить файлик с исключениями.
ещё стоит заметить, что ECH не всегда срывает сайты которые вы посещали. например эти данные можно получить анализируя DNS трафик. эту проблему легко решить настройкой DoH. когда можно однозначно сопоставить IP адрес имея сайта не поможет ничего. например случаях когда на одном IP один единственный сайт или когда вся CDN построена для одного единственного сайта.
т.е если на CDN весит 5000 сайтов провайдер видит что вы обращались к одному из IP принадлежащему CDN на которой 5000 сайтов. если же это выделенный сервер с сайтом, то не поможет ничего, т.к. сетевому адресу (IP) можно однозначно сопоставить DNS имя.
ну и напоследок взглянем на прямой трафик ютуба. т.е. на трафик пользователей не использующих VPN
P.S
нашел в интернете ещё вот это
--dpi-desync=multidisorder
--dpi-desync-split-pos=2,5,host+5,sld-1,endsld-5,endsld,sniext
ребята это работает :))) от осознания профессионализма РКН прыгал под столом полчаса от смеха. т.е. вы можете завернуть весь трафик в некую бесплатную программку и ничего не сломается, но зато будет доступны и ютуб и рутрекер. и эти люди пытаются мне что-то в интернете запрещать - ну удачи.
Публикации по теме: