Странно то, что при блокировках по ФЗ у людей и так все счета во всех банках сразу отваливаются, значит, о каждом счёте им централизованно известно, кому он принадлежит и какие там ещё есть счета. Как в этой схеме добавление ИНН уменьшит риск мошенничества?
CORS не поможет, владелец зонда разрешит другим сайтам пользоваться им. Тут разве что расширения браузера наподобие uMatrix могут помочь, явно запретив одним сайтам дёргать ресурсы с других сайтов, но проще в таком случае отдельный браузер на виртуалке, трафик с которой гонится напрямую.
Что-то математика у этих исследователей слегка не сходится:
Как ClientHello может оказаться в пределах 513 байт в их случае, если в этом пакете и так применяется мимикрия под пост-квантовый Хром, у которого доля ключа X25519MLKEM768 занимает ровно 1216 байт? Padding там математически никак не может оказаться в пакете. Может, конечно, это на будущее борьба с хрупким кодом, если в современном Хроме выкинут алгоритм с большим ключом (чтоб их код случайно не поломался при адаптации под новый Хром), но критической серьёзности тут в упор не вижу, всё равно в таком случае придётся сравнивать пакеты и несостыковка выплывет наружу.
И в доквантовые времена не припомню также, чтобы padding в каких-нибудь браузерах генерировался рандомной длины, как раз этот параметр дополняет пакет до строго фиксированной длины, если пакет слишком короткий (а случайный с потрохами сдал бы).
Нет, он присутствует в любом запросе более-менее современного браузера. Либо реальный, если ECH поддерживается сервером и клиент знает параметры, либо рандомно сгенерированный муляж (ECH Grease).
Для серверной тоже вроде как подняли (если текст в статье достоверный):
Серверная версия Ubuntu 26.04 LTS теперь требует 1.5 ГБ оперативной памяти, когда Ubuntu 22.04 требовала всего 1 ГБ, а 18.04 всего 512 МБ. Для сравнения, Windows 11 требует минимум 4 ГБ ОЗУ.
ECH Grease (муляж ECH-расширения) все браузеры ещё с начала появления ECH отправляют, чтобы цензор не знал по хендшейку, есть ли внутри реальный ECH или он только маскировочный.
А Cloudflare ECH блокировали по маскировочному SNI, а не по наличию технологии ECH (а теперь уже тупо замедляют вообще по диапазонам IP, если SNI не один из одобренных).
Цепочки меняются, к примеру, CDN-сервера внутри стран могут значительно разгрузить объём трафика наружу, кешируя и раздавая часто запрашиваемые статичные файлы пользователям внутри страны. Но с VPN каждый файл придётся снаружи тянуть отдельным экземпляром.
Тем, что по некоторым направлениям фильтрация более строгая, а по некоторым - менее?
Притом по моим ощущениям, она выборочно включается периодически, сначала долго всё нормально, потом вдруг перестаёт нормально работать, потом через какое-то время снова всё нормально (может быть ещё зависит от того, на какой ТСПУ попадёт балансировка нагрузки или каким маршрутом трафик пойдёт).
StartPermutationElement(); {
S("\xfe\x02"_q); // <--- id расширения должно быть 0xEF0D вместо 0xFE02
OpenScope();
S("\x00\x00\x01\x00\x01"_q);
R(1);
S("\x00\x20"_q);
R(20); // <--- перепутали 20 и 0x20, ну бывает
OpenScope();
E();
CloseScope();
CloseScope();
}
Из-за подобных косяков оно легко определяется. Может быть, это не единственный косяк у них, вызывающий явные подозрения у фильтрующего оборудования.
Pull Request для исправления есть, надеюсь что его быстро примут и обновят клиент.
Или настроить, чтобы выходной IP не совпадал с входным. Я себе на выходе давно WARP воткнул, ибо сплит-туннелирование по доменам/cidr ненадёжно (никто не мешает шпионам поднять зонд за пределами РФ)
2026 год на дворе, а они для контроля целостности используют MD5. А может быть и намеренно для лёгкой подмены при необходимости.
Странно то, что при блокировках по ФЗ у людей и так все счета во всех банках сразу отваливаются, значит, о каждом счёте им централизованно известно, кому он принадлежит и какие там ещё есть счета. Как в этой схеме добавление ИНН уменьшит риск мошенничества?
Это бета, а новость про стабильную ветку
Он ещё давно там был сломан, судя по датам багрепортов
На Андроид только что прилетел фикс, с красивым номером билда 😈
Скрытый текст
Полёт пока нормальный
CORS не поможет, владелец зонда разрешит другим сайтам пользоваться им. Тут разве что расширения браузера наподобие uMatrix могут помочь, явно запретив одним сайтам дёргать ресурсы с других сайтов, но проще в таком случае отдельный браузер на виртуалке, трафик с которой гонится напрямую.
Что-то математика у этих исследователей слегка не сходится:
Как ClientHello может оказаться в пределах 513 байт в их случае, если в этом пакете и так применяется мимикрия под пост-квантовый Хром, у которого доля ключа X25519MLKEM768 занимает ровно 1216 байт? Padding там математически никак не может оказаться в пакете. Может, конечно, это на будущее борьба с хрупким кодом, если в современном Хроме выкинут алгоритм с большим ключом (чтоб их код случайно не поломался при адаптации под новый Хром), но критической серьёзности тут в упор не вижу, всё равно в таком случае придётся сравнивать пакеты и несостыковка выплывет наружу.
И в доквантовые времена не припомню также, чтобы padding в каких-нибудь браузерах генерировался рандомной длины, как раз этот параметр дополняет пакет до строго фиксированной длины, если пакет слишком короткий (а случайный с потрохами сдал бы).
Нет, он присутствует в любом запросе более-менее современного браузера. Либо реальный, если ECH поддерживается сервером и клиент знает параметры, либо рандомно сгенерированный муляж (ECH Grease).
Для серверной тоже вроде как подняли (если текст в статье достоверный):
24.04 тоже 1Гб требовала
ECH Grease (муляж ECH-расширения) все браузеры ещё с начала появления ECH отправляют, чтобы цензор не знал по хендшейку, есть ли внутри реальный ECH или он только маскировочный.
А Cloudflare ECH блокировали по маскировочному SNI, а не по наличию технологии ECH (а теперь уже тупо замедляют вообще по диапазонам IP, если SNI не один из одобренных).
На бюджетных гигабайтных VPS теперь она не встанет. Хотя для подобных систем всё равно лучше какую-нибудь Alpine воткнуть.
Цепочки меняются, к примеру, CDN-сервера внутри стран могут значительно разгрузить объём трафика наружу, кешируя и раздавая часто запрашиваемые статичные файлы пользователям внутри страны. Но с VPN каждый файл придётся снаружи тянуть отдельным экземпляром.
Может быть, различные костыльные решения вроде таких не до конца удушены
Было внесено в ветку dev этим коммитом, ждём теперь в проде
Тем, что по некоторым направлениям фильтрация более строгая, а по некоторым - менее?
Притом по моим ощущениям, она выборочно включается периодически, сначала долго всё нормально, потом вдруг перестаёт нормально работать, потом через какое-то время снова всё нормально (может быть ещё зависит от того, на какой ТСПУ попадёт балансировка нагрузки или каким маршрутом трафик пойдёт).
Если интересуют технические подробности, то разработчики Telegram налажали в коде генерации TLS-расширения encrypted_client_hello:
Telegram/SourceFiles/mtproto/details/mtproto_tls_socket.cpp
Из-за подобных косяков оно легко определяется. Может быть, это не единственный косяк у них, вызывающий явные подозрения у фильтрующего оборудования.
Pull Request для исправления есть, надеюсь что его быстро примут и обновят клиент.
Или настроить, чтобы выходной IP не совпадал с входным. Я себе на выходе давно WARP воткнул, ибо сплит-туннелирование по доменам/cidr ненадёжно (никто не мешает шпионам поднять зонд за пределами РФ)
В EE-ключах к 16-байтному (17 с учётом префикса) ключу дописан SNI, которым притворяться
А если неофициальный клиент начнёт притворяться официальным? Как будет проверяться достоверность официального клиента?
И простенькой анимации ударов, чтобы было наглядно видно, кто кого атаковал и контратаковал