Сегодня перестало работать. 2 - 3 хендшейка прошли, на следующие пишет что сервис не доступен (приложение андроид).
Смена порта на 443 не помогает, даже первый хендшейк не прошел.
Содержимое трафика они знать не могут, оно же шифрованное. Единственное, что можно предположить, что используются какие-то паттерны по последовательности пакетов определенного размера, которая проявляется при установке HTTPS соединения внутри туннеля. И вероятно, это может зависеть от браузера, его версии, применяемого в SS шифрования.
Однако, судя по описанию формата пакетов на оф.сайте, они должны быть рандомного размера для предотвращения подобного рода детектирования.
Правда с оговоркой:
The random salt and header chunks MUST be buffered and sent in one write call to the underlying socket. Separate writes can result in predictable packet sizes, which could reveal the protocol in use.
Может в каком-то из серверов и/или клиентов SS есть недоработка, вытекающая в предсказуемый размер пакетов?
Похоже и на это пофиксили блокировки.
Как понял в SS не всё шифруется, а часть данных. Возможно на это паттерны. Поведение такое, как-будто с dns-запросами проблемы возникают.
Блокируют на ТСПУ. Блокируют не только SS. Первое условие, помимо неизвестного содержимого: размер запроса.
На старом SS нет padding, но размер запроса зависит еще и от длины домена. Приложение может начинать с днс резолва (DoH через SS), а у SS сервера запрашивать подключение уже к IP адресу. Вероятность блокировки похожа на неизвестное распределение от 0 до MSS.Но в районе 600-900 байт блокировка стабильней. Блокировки сосредоточены вокруг определенных точек (100, 500, 600, 900 и прочее), размер ответа влияет на вердикт. Часть диапазонов блокируемых запросов требуют больших ответов. Похоже на попытку заблокировать только HTTP и HTTPS через SS, или трафик конкретного приложения.
Непонятно, влияет ли блокировка на последующие сессии, или это зависит от ТСПУ. Непонятно, влияет ли ответ.
Вы же пишете, что у вас http проходит, а блокировка после редиректа на https.
Чтобы подключиться с сайту, сначала должен пройти dns-запрос, только потом http-запрос, и после этого редирект на https, без повторного dns-запроса.
Меня смутил в дампе открытый адрес ресурса, хотя в настройках системы стоит безопасный dns, это именно после редиректа на https:
Спойлер
это https sni
Как понял в SS не всё шифруется, а часть данных.
Нет, в SS трафик шифруется целиком
Может в каком-то из серверов и/или клиентов SS есть недоработка, вытекающая в предсказуемый размер пакетов?
Насчет этого не слышно, но точно известно, что в некоторых SS-серверах (а возможно даже в большинстве) есть недоработка, позволяющая детектировать их через active probing: Active probing weakness found in the Xray implementation of Shadowsocks · Issue #625 · XTLS/Xray-core · GitHub (там длинное обсуждение, и оно далеко не только про XRay).
Плюс у Shadowsocks без дополнений есть особенность by design что он шлет TCP как TCP и UDP как UDP. То есть на один и тот же IP и порт будут подниматься TCP-сессии и летать короткие UDP-пакеты (как минимум DNS-запросы) - это очень характерный паттерн. И из-за этого же могут быть очень интересные глюки при блокировках, например, когда режут все неизвестные протоколы по TCP, но не трогают UDP, то через SS может открываться только часть сайтов (те, что используют QUIC), а остальные уже нет, ну и соответственно может быть и наоборот.
Именно поэтому советуют 1) использовать Shadowsocks-2022 вместо ванильного Shadowsocks 2) при использовании SS обязательно включать UoT (UDP-over-TCP), благо он сегодня поддерживается во всех приличных клиентах
Кстати, похоже правда про недоработку в ss клиентах: МТС в Мск похоже блокирует впн через outline (на ios сайты не открываются с ошибкой невозможности установки безопасного соединения, при этом работает инстаграм и телега), а через shadowrocket с тем же сервером все работает отлично.
Добралось до меня, исследую.
Я опечатался, не “клиентах”, а “серверах”. На клиенте там сложно что-то не так сделать, на самом деле, скорее проблема в чем-то другом.
На Хабре буквально сегодня появилась статья про приколы с IPv6 при использовании прокси, больше похоже вот на это.
2022_blake3 это есть SS2022?
Поведение блокировок аналогично обычному SS описанному выше.
Йота/Мегафон. Блокируется shadowsocks-2022. Подключение проходит, но данные не идут. На проводном - работает.
Блокируются все неклассифицируемые (полностью зашифрованные) протоколы, если шаблон данных напоминает HTTPS.
Завернул shadowsocks-2022 в cloak, работает.
Причем, cloak на нестандартном порту, и этот порт не доступен на домене для редиректа.
Возможно ркн не использует active probing, либо тупо проверяет всегда 443 порт.
И?
Да, похоже блокировка доехала до Москвы. Наблюдаю у себя на МТС моб. и Билайн моб. На проводных провайдерах не наблюдается. Использую чистый SS, сервер shadowsocks-libev, клиенты классический Shadowsocks и Nekobox.
Блокировка наблюдается именно при попытке открытия https сайтов. Причем блокировка не 100% - иногда проходит соединение, иногда - нет, что на это влияет - не понятно.
А блокировка при этом воспроизводится из этой темы?
Есть нюанс. Блокировка из той темы воспроизводится, но только на проводном интернете. А блокировка Shadowsocks, наоборот, только на мобильном.