Есть различия в реализации ClientHello HTTP/3 (QUIC), в Chrome есть дефолтное фрагментирование (с целью чтобы у разработчиков на серверной стороне не было соблазна реализовать протокол в упрощенном варианте, не соответствующем стандарту). Из-за недоработок обработки пакетов некоторых DPI это во многих случаях не позволяло этому оборудованию увидеть SNI *googlevideo.com и применить "замедление". Возможно сегодня выкатили сделанную на коленке заплатку на РТК, что такие соединения просто блокировались какое-то время (а также уже традиционно и Google Play). Но там еще много странностей сегодня замечено.
Впрочем неважно. Решения для устранения "замедления" давно известны, и они по-прежнему актуальны.
Я не про ECH, а про AEAD пакетов пакетов QUIC initial. Для DPI это уже надо расшифровывать. Для этого все есть, но несколько затратнее с точки зрения вычислительных мощностей (как серверных так и тех которые в головах разработчиков). Кстати, помню там различное поведение было в зависимости от версии draft, год-два назад DPI не для всех SNI вытаскивать умели, и даже отдельный фильтр по версии был.
Что еще явно влияет. Дефолтная фрагментации CH в Chome. Да, сейчас у популярных представленных DPI вендоров реассемблинг реализован кое как. Например известный трюк изменение порядка пакетов. И еще много других трюков есть. Конечно не сложно сделать нормально. Ценой увеличения требований к ресурсам. Пока практика такова, что анализируют первые N пакетов, что предоставляет очевидные возможности. Также внедряются доп уровни более глубокого анализа, не статические правила. Конечно же со временем закроют простые лазейки. Но это тоже не бесплатно.
Учитывайте многочисленные утечки памяти в xray-core. Часть недавно исправили, но часть никуда не делась. С учетом этого "2 Гб, но не меньше 1 Гб." адекватные цифры. Очень сильно зависит от используемых опций, но расчитывать уместиться в 256 точно не стоит.
Не будут они переподписывать. Просто не будут отдавать DNS-записи, относящиеся к DNSSEC, отключив в рунете подписи зон и открывая дорогу к подменам резольва записей.
Начиналось с создания резервной системы DNS в целях безопасности на случай отключения извне вредителями, а в итоге сами же изолируют его изнутри. Никаких вредителей извне даже не потребовалось.
Сначала создали реестр РКН исключительно "для защиты детей от вредной информации о суицидах и наркотиках", теперь блокируют даже протоколы, пропуская трафик по белым спискам. Заблокировали QUIC (очевидно от защиты детей от его тлетворного влияния), заблокировали ECH, успешно протестировали блокировку DoH/DoT и доступа к популярным публичным DNS поддерживающим шифрование, совершенствуют внеерестровые блокировки "запрещенных" протоколов на ТСПУ (попутно ломая все что можно, но делая огромные деньги на этом оборудовании, заранее скупив его разработчиков), теперь вот двигаются дальше к суверенному чебурнету светлому будущему.
Еще немного и можно будет рапортовать начальству об успехах, получать награды.
Осталось еще уголовку за использование шифрования ввести. Или за факт выхода в международный сегмент интернета.
А тем временем некоторые провайдеры (дом ру) уже делают подмену DNS ответов.
P.S. Вспоминаю, как еще недавно были времена, когда те же самые люди пытались внедрить DNSSEC для безопасности зоны .ru, а теперь сами же убивают все труды.
В чем конкретно заключается опасность повышенного содержания железа? Или речь исключительно об органолептических показателях и влиянии на эффективность работы последующих фильтров?
Есть различия в реализации ClientHello HTTP/3 (QUIC), в Chrome есть дефолтное фрагментирование (с целью чтобы у разработчиков на серверной стороне не было соблазна реализовать протокол в упрощенном варианте, не соответствующем стандарту). Из-за недоработок обработки пакетов некоторых DPI это во многих случаях не позволяло этому оборудованию увидеть SNI *googlevideo.com и применить "замедление". Возможно сегодня выкатили сделанную на коленке заплатку на РТК, что такие соединения просто блокировались какое-то время (а также уже традиционно и Google Play). Но там еще много странностей сегодня замечено.
Впрочем неважно. Решения для устранения "замедления" давно известны, и они по-прежнему актуальны.
Это не подозрение, а давно известный факт. Именно это и является причиной замедления, а не "устаревшие кэширующие сервера".
А еще коннекты ECH можно легко блокировать на ТСПУ. Тем более прецеденты блокировки соединений из пакетов которых не могут вытащить SNI уже были.
Можете найти упоминание разных вариантов самими разработчиками как xray-core, так и сопутствующего софта (популярных панелей и скриптов).
Я не про ECH, а про AEAD пакетов пакетов QUIC initial. Для DPI это уже надо расшифровывать. Для этого все есть, но несколько затратнее с точки зрения вычислительных мощностей (как серверных так и тех которые в головах разработчиков). Кстати, помню там различное поведение было в зависимости от версии draft, год-два назад DPI не для всех SNI вытаскивать умели, и даже отдельный фильтр по версии был.
Что еще явно влияет. Дефолтная фрагментации CH в Chome. Да, сейчас у популярных представленных DPI вендоров реассемблинг реализован кое как. Например известный трюк изменение порядка пакетов. И еще много других трюков есть. Конечно не сложно сделать нормально. Ценой увеличения требований к ресурсам. Пока практика такова, что анализируют первые N пакетов, что предоставляет очевидные возможности. Также внедряются доп уровни более глубокого анализа, не статические правила. Конечно же со временем закроют простые лазейки. Но это тоже не бесплатно.
Да, в последние месяцы известная история. Переодически наблюдаются блокировки подозрительного трафика в адрес DO, Hetzner и некоторых других.
bash <(curl i.hiddify.com/release)Congratulations, the installation is complete.Или по видео для совсем неопыных - https://hiddify.com/manager/installation-and-setup/guide/#installation-video
Не знаю что имел в виду автор. Под self-host в контексте reality обычно имеется в виду сайт под который маскируемся.
Учитывайте многочисленные утечки памяти в xray-core. Часть недавно исправили, но часть никуда не делась. С учетом этого "2 Гб, но не меньше 1 Гб." адекватные цифры. Очень сильно зависит от используемых опций, но расчитывать уместиться в 256 точно не стоит.
Все проще. В одном случае SNI передается в открытом виде. Во втором нет, точнее, возможны варианты.
Если же интересно реальное сравнение скорости протоколов без влияния замедлений ТСПУ, то тестировать нужно как минимум с фрагментированием SNI.
Как какой-то доклад студента 1 курса гуманитарного ВУЗа которую кто-то решил опубликовать спустя много лет?
Или статья написанная копирайтером-домохозяйкой в соавторстве с ChatGPT потому что у редакции есть единственный KPI по количеству постов в неделю?
Как это попало сюда? И почему выводится на главной странице?
Это ради обхода законодательства о персональных данных или...?
И грязные айпишники?
С каких пор там последняя версия? Или недавно наконец-то обновили?
Нет, он не мимикрирует под обычный HTTPS трафик. Для наблюдателя он выглядит как шифрованный поток данных. TLS-хэндшейка там вообще нет.
Там ss старой уязвимой версии. Но в РФ блокировали не сам SS протокол, а "все непонятное" (кроме протоколов из белого списка).
Не будут они переподписывать. Просто не будут отдавать DNS-записи, относящиеся к DNSSEC, отключив в рунете подписи зон и открывая дорогу к подменам резольва записей.
Начиналось с создания резервной системы DNS в целях безопасности на случай отключения извне вредителями, а в итоге сами же изолируют его изнутри. Никаких вредителей извне даже не потребовалось.
Сначала создали реестр РКН исключительно "для защиты детей от вредной информации о суицидах и наркотиках", теперь блокируют даже протоколы, пропуская трафик по белым спискам. Заблокировали QUIC (очевидно от защиты детей от его тлетворного влияния), заблокировали ECH, успешно протестировали блокировку DoH/DoT и доступа к популярным публичным DNS поддерживающим шифрование, совершенствуют внеерестровые блокировки "запрещенных" протоколов на ТСПУ (попутно ломая все что можно, но делая огромные деньги на этом оборудовании, заранее скупив его разработчиков), теперь вот двигаются дальше к
суверенному чебурнетусветлому будущему.Еще немного и можно будет рапортовать начальству об успехах, получать награды.
Осталось еще уголовку за использование шифрования ввести. Или за факт выхода в международный сегмент интернета.
А тем временем некоторые провайдеры (дом ру) уже делают подмену DNS ответов.
P.S. Вспоминаю, как еще недавно были времена, когда те же самые люди пытались внедрить DNSSEC для безопасности зоны .ru, а теперь сами же убивают все труды.
В чем конкретно заключается опасность повышенного содержания железа? Или речь исключительно об органолептических показателях и влиянии на эффективность работы последующих фильтров?
Значения подозрительно похожи на замедление трафика некоторыми провайдерами.
SNI