Что решает в интернетах РКН?

недавно получил знак качества от РКН — отредактированная копия здесь. ну думаю раз народу нравится надо написать по этой теме еще. ну начнем мы с года так около 2000. что было в интернете РФ в 2000? его в называли диким потому что никем и ни как не регулировался. сказать что это был век свободы и всеобщего благополучия тоже нельзя сказать. законы страны на серверах находящихся внутри страны должны соблюдаться уж точно, а вот распространять их на весь интернет занятие глупое и бесполезное.
запрещать что-то наверное можно и нужно, но тут стоит сразу сделать шаг назад: например YouTube, которым пользуется 80 процентов населения, запретить невозможно, ну обо все по-порядку.
вернемся к нашим 2000. весь интернет был http. т.е. данные передавались в открытом виде. соответственно такие данные легко отфильтровать по содержимому пакета в котором они передаются. такая технология называется Deep Packet Inspection - DPI. я уж не буду говорить какой он бывает — нам важна суть.
и принципе это был неплохой инструмент, если его грамотно использовать. грамотно это как? грамотно т.е. для блокировки сайтов и страниц с запрещенными товарами и информацией, чтобы у людей не было особого желания блокировку обходить. в любом случае её обойти можно — было бы желание, но как метод оградить массы от заведомо противозаконной информации вполне себе.
в свое практике я правда применял его для иных целей - все эти управляющие сообщения сети тоже передаются в открытом виде и их положение в пакете фиксированное и хорошо поддается такому методу фильтрования, что дает возможность повысить безопасность или избавиться от нежелательных сетевых сервисов.
но как водится возможность что-то точечно запретить привело российских чиновников в экстаз и запрещать стали практически все неугодное и интернет быстро превратился из http в https. S — значит Security. что вобщем-то практически обесценило применяемые методы блокировки. осталось возможным только заблокировать старым добрым firewall (по ip-адресу) или выпилить имя из DNS.
для установки соединение https используется специальный протокол обмена ключами, которые обеспечивают защищенное соединение т.е. проверяется аутентичность. сами данные предаются в шифрованном канале невидимые третей стороне. про криптостойкость говорить особого смысла нет — в любом случае нужны очень серьёзные ресурсы даже для отслеживания одного соединения.
я не буду рассматривать SSL, TLS и версии TLS скажу, что сейчас обычно используется TLS 1.3 именно с помощью этого протокола сейчас как правило устанавливается защищенное соединение на транспортном уровне.
никакие данные внутри https не доступны. но кого-то сажают — как это происходит? ну во-первых сайт сам может передать статистику в компетентные органы — это требование закона. второй путь это сторонние службы например e-mail или яндекс-паспорт, аватарка, логи вашего браузера и т.п.
вроде бы все хорошо — соединение защищено, но довольно быстро нарисовалась проблема. дело в том что обмен ключами осуществлялся по довольно «наивной» схеме. и соединение при определенной сноровке можно было контролировать. и после разоблачений Сноудена проблема была признана значительной и так появился TLS 1.3. который вроде бы закрыл все потребности в безопасности.
но время идет и в ~2022 году кому в РКН пришла гениальная мысль, что имя домена (Server Name Indication SNI) в TLS 1.3 обычно в начале установки соединения передается в открытом виде. вы скажите что это дыра? как разработчики TLS такое допустили? не все так просто. серверу нужно знать к какому домену вы обращаетесь т.к. на одном IP-адресе может быть несколько доменов. и иметод отбрасывания пакета TLS Handshake с не шифрованным SNI применили для блокировки YouTube. как я уже сказал идея сомнительная и я думаю поставит крест на ТСПУ. почему?
первое это то что такую блокировку легко обойти локально т.е. без использования VPN.
второе народу много и спрос рождает предложение. быстро появились программки бесплатные и не очень, которые позволяют блокировку обойти «простым смертным».
ну а что же TLS? уже сейчас существуют расширения которые позволяют шифровать имя домена во время обмена ключами, более того включены по умолчанию в современных браузерах.
но почему нет поддержки на серверах? этого я не знаю, кроме того есть некоторые уязвимые места в этой системе.
но совершенно точно внедрение этой технологи обесценивает ТСПУ. вот такая одноразовая, как одно резиновое изделие, штука получилась. я думаю неэффективность закупки оборудования на лицо.
ну а когда можно будет ожидать внедрения например технологии TLS-ECH, которая мало того что полностью шифрует процесс обмена ключами, но и датой своего появления намекает на техническую грамотность работников РКН? точно не завтра. этой штуке как минимум понадобоиться куча серверов DoH, что вообще говоря является уязвимостью.
вывод такой: скромнее нужно чиновникам из РКН быть, а не размахивать тем чем обычно с колокольни облака разгоняют — может быть и люди к вам потянутся.
|
</> |