блин, не могу найти инфу) Но где-то видел что будет импрув по защите конфиденциальности пользователя

блин, не могу найти инфу) Но где-то видел что будет импрув по защите конфиденциальности пользователя

либо они как-то могут поломать идентификацию пользователя за счет форварда реквестов друг между другом

Кстати, если не игрались с shadowsocks то совеотую попробовать. )

Кстати, если не игрались с shadowsocks то совеотую попробовать. )

Начать можно с outline, ибо он работает поверх него и вообще максимально классный

Классный, как минимум, благодаря нативным приложениям под телефоны

На электроне))

На телефоны тоже?

Как уже сказали для нас эта обфускация роли мало играет, РКН пока по DPI не банит и начнет не скоро. Но это поможет Иранцам.

Банит то не РКН. В новостях уже было, что некоторые операторы OpenVPN по DPI блокировали

Люблю такие ситуации когда читаешь последние 100 сообщений и ни одного не понимаешь :)

Банит то не РКН. В новостях уже было, что некоторые операторы OpenVPN по DPI блокировали

Банит то не РКН. В новостях уже было, что некоторые операторы OpenVPN по DPI блокировали

Вообще, насчет мтпрото-прокси интересно, как именно текущее их устройство помогает не палиться от dpi

Насчет маскировки под TLS я немного слукавил и меня поправили специалисты: Обфускация "anti-DPI" там простая. Генерят на клиенте случайный 32-байтовый ключ и 16-байтовый IV, ими шифруют пакет с AES CTR и отправляют. При этом сами ключ и IV отправляются перед зашифрованной нагрузкой. В итоге, если вы провайдер, вам нужно ВСЕГО ЛИШЬ* брать от каждого исходящего пакета 8-40 байты (ключ) и 40-56 байты (IV), расшифровывать содержимое (64-... байты). В расшифрованном содержимом уже вполне стандартный mtproto-формат, где первые 8 байт — сигнатура авторизационного ключа. Поймали несколько пакетов, где первые 8 байт после расшифровки совпадают — смело вносим конечный адрес в реестр запрещённых ресурсов. *насчёт ВСЕГО ЛИШЬ и почему я вообще об этом открыто говорю, не боясь дать подсказку РКН: сама идея слишком простая, глупая, а защиты-то по сути никакой, но вот только ни у одного провайдера не хватит мощностей каждый пакет расшифровывать с AES-256 и какие-то проверки проводить на предмет наличия там Telegram.

Блокировали охеревшие операторы (йота, например, резала скорость по нему, не знаю как сейчас)

Банит то не РКН. В новостях уже было, что некоторые операторы OpenVPN по DPI блокировали

Насчет маскировки под TLS я немного слукавил и меня поправили специалисты: Обфускация "anti-DPI" там простая. Генерят на клиенте случайный 32-байтовый ключ и 16-байтовый IV, ими шифруют пакет с AES CTR и отправляют. При этом сами ключ и IV отправляются перед зашифрованной нагрузкой. В итоге, если вы провайдер, вам нужно ВСЕГО ЛИШЬ* брать от каждого исходящего пакета 8-40 байты (ключ) и 40-56 байты (IV), расшифровывать содержимое (64-... байты). В расшифрованном содержимом уже вполне стандартный mtproto-формат, где первые 8 байт — сигнатура авторизационного ключа. Поймали несколько пакетов, где первые 8 байт после расшифровки совпадают — смело вносим конечный адрес в реестр запрещённых ресурсов. *насчёт ВСЕГО ЛИШЬ и почему я вообще об этом открыто говорю, не боясь дать подсказку РКН: сама идея слишком простая, глупая, а защиты-то по сути никакой, но вот только ни у одного провайдера не хватит мощностей каждый пакет расшифровывать с AES-256 и какие-то проверки проводить на предмет наличия там Telegram.

А что в первых восьми байтах передается?

Какие первые 8 байт в хендшейке, вот о чем я)

Судя по всему, первые 8 байт вообще могут быть любым, затем идет рандомный ключ, который суммируется с секретом и этой парой расшифровывается зашифрованная часть

На чем ботов нужно писать?

надо просто подождать какой-нибудь метод

На чем ботов нужно писать?

Так погоди, разве эти вещи уже не в зашифрованном виде идут?

Это же не про mtproto прокси?

Насчет маскировки под TLS я немного слукавил и меня поправили специалисты: Обфускация "anti-DPI" там простая. Генерят на клиенте случайный 32-байтовый ключ и 16-байтовый IV, ими шифруют пакет с AES CTR и отправляют. При этом сами ключ и IV отправляются перед зашифрованной нагрузкой. В итоге, если вы провайдер, вам нужно ВСЕГО ЛИШЬ* брать от каждого исходящего пакета 8-40 байты (ключ) и 40-56 байты (IV), расшифровывать содержимое (64-... байты). В расшифрованном содержимом уже вполне стандартный mtproto-формат, где первые 8 байт — сигнатура авторизационного ключа. Поймали несколько пакетов, где первые 8 байт после расшифровки совпадают — смело вносим конечный адрес в реестр запрещённых ресурсов. *насчёт ВСЕГО ЛИШЬ и почему я вообще об этом открыто говорю, не боясь дать подсказку РКН: сама идея слишком простая, глупая, а защиты-то по сути никакой, но вот только ни у одного провайдера не хватит мощностей каждый пакет расшифровывать с AES-256 и какие-то проверки проводить на предмет наличия там Telegram.

Конечно, никто не мешает в рамках одного инстанса слушать кучу портов и размазывать секреты по портам

1. Не выйдет так просто это дело расшифровать оператору (да и так сложно) 2. Добавлять дополнительные секреты и впрямь ПРОБЛЕМАТИЧНО

Вот погляди, кстати, мне кажется на этом этапе ещё нет шифрования https://core.telegram.org/mtproto/samples-auth_key

Потому что этот этап идет уже после соединения с проксёй (:

Так провайдеру для этого нужно знать секрет, с которым пользователь подключается к проксе

Если провайдер его знает => провайдер, думаю, и адрес прокси там же может посмотреть :D

авторы @TgVPNbot мансят от РКН уже месяц, прокси до сих пор стабильно работает

Вот погляди, кстати, мне кажется на этом этапе ещё нет шифрования https://core.telegram.org/mtproto/samples-auth_key

Что такое мансят? Ради этого даже в чат заглянул. Яндекс не помог по этому запросу всего 2к страниц нашёл

но если уже авторизованный пользователь включит прокси, этот этап не будет выполняться заново, сразу пойдет шифрованный трафик

также надо иметь в виду, что и шифрованный и плейнтекст трафик Телеграм обфусцирует дополнительно. Логически это легко разобрать обратно, но на практике для DPI может быть сложна такая массовая обработка