уже 6.7.5 выкатили
х.з. чем лучше
но поведение одинаково в нём и древнем 4.6.1
прокси постоянно галка\кружок и т.д.
своего прокси нет чтоб понять перегруз или чебуроды поменяли что. промежуточные версии без изменений - наглухо
Чтоб понять можно VPN включить и посмотреть, изменится ли поведение.
согласен. в этот раз затупил . хотя раньше так и делал
просто по дефолту тг и так через протон а прокси мимо
полный vpn подсказал что всёже сервак не аллё
Десктоп продолжает работать, но ведроидная версия 12.6.4 перестала на всех доступных мне провайдерах.
Палят именно handshake.
Приходит только первая часть сэмулированного кибер hello. ТСПУ пока не собрал пакеты пропускает. Когда последний пакет приходит, он возбуждается и рубит сессию вместе с последним пакетом.
Удалось в какой-то степени обойти через z2 на серваке
С 1го апреля перестал работать, так и не работает после нашумевшего обновления (речь про desktop).
Имелась в виду версия десктопа 6.7.2, где исправили вопиющие палева с handshake.
Без этих исправлений есс-но не работает.
Ведро тоже починили в 12.6.4 beta, но проработало оно буквально 1-2 дня, сейчас опять нет
Причем это точно не статистика и не ML. Еще нашли какое-то палево в handshake
Так у меня и новый 6.7.2 не работал никогда. И это с учетом того, что старые носки до 1го апреля работали прекрасно даже на старых клиентах.
6.7.2 исправил проблему только с fake tls, которую запалили в апреле блокираторы
Протокол mtproto сам по себе легко детектируется, а носки ничего не шифруют
Ваша программа Zapret 1 легко справилась с блокировкой socks5, чистый MTProto не проверял, но с fake tls у моего провайдера проблем не было вообще.
О, интересно. А ByeByeDPI на андроиде можно настроить на дурение трафика MTProto?
С десктопом проблем нет, а вот на андроиде никакие прокси не работают. Одно конкретное только сегодня хрипело предсмертным хрипом полдня, а к вечеру умерло вслед за остальными. Как то вообще не почувствовал никаких “фиксов” обнаружения прокси на андроиде…
Ещё я слышал, что при выборе публичных MTProto, надо смотреть на первые 2 символа в secret. Есть определённые прокси, которые считаются более живучими, лучше маскирующимися под современные реалии ТСПУ.
9.4.2. ведро полёт нормальный
агрятся на последнее…
оттого и дурик в подозрениях об сговоре - сами правки mtproto с добавкой палева полугодичные
Судя по исправлениям там пытались сделать показную эмуляцию ech, но накосячили в ID и в длине поля перепутали dec и hex. 0x забыли
Кто-то сообщил разработчикам Telegram, не видели?
В тот же день PR оформили и вечером тестовый билд был.
но накосячили в ID и в длине поля перепутали dec и hex. 0x забыли
Я так понял, что исправили криво, и теперь проблема в этом.
Вот что нейронка выдает:
В чем именно «накосячили»?
Ошибка находится в Payload (полезной нагрузке) расширения ECH, которая начинается с байта 00 на смещении 0x00A3. Согласно спецификации TLS ECH, структура ECHClientHello (outer) должна содержать набор параметров HPKE (KEM, KDF, AEAD).
Посмотрим на байты с 0x00A3:
00 00 01 00 01 f2 00 20 ...
По стандарту поля должны идти так:
00 — type (outer)
00 01 — kem_id (2 байта)
00 01 — kdf_id (2 байта)
f2 — aead_id — ОШИБКА №1
Суть ошибки:
Поле AEAD ID в протоколе TLS обязано быть 2-байтовым. Здесь же под него выделили всего 1 байт (f2).
Если разработчик хотел использовать GREASE-значение (например, 0xF2F2), то из-за «забытого 0x» или ошибки в коде (использование uint8 вместо uint16) в дамп попал только один байт.
Из-за того, что поле AEAD «съело» 1 байт вместо 2, все последующие данные сместились.
Он как обычно глючит. Выдумывает.
Посмотрел tls handshake от десктоп 6.7.5 и ведро 12.6.4
В обоих версиях идет так
00 - client hello type - outer
00 01 - kdf id
00 01 - aead id
cb - случайный байт config id
00 20 - enc length - 32 байта
32 байта рандом
00 90 - длина пейлоада. длина рандом в некоторых пределах
рандомный пейлоад
kem_id шарк вообще не показывает
f2 - это config id в примере, дальше 00 20 - enc length
у вебкита все 1 в 1
Значит, периодические отвалы подключений определяются по каким-то другим паттернам. Возможно, пытаются определить reality в том числе.
Теоретически да, можно
для tcp
--fake -5 --fake-sni белый_сни --fake-tls-mod rand --ttl от_1_до_20
для udp
--udp-fake число_репитов --fake-data quic_с_белым_сни.bin --fake-tls-mod msize=1200 --ttl от_1_до_20
добрались и до старых телег
из 5ти проксей что доступны через vpn
без vpn 2е недоступны полностью ещё 2е с перебоями, туже медию почти никак
и только одна полностью рабочая
либо научились вычислять какие именно левые sni в ключе либо сами серваки кривые
хмм…
реальность оказалась ещё интересней
достаточно переподключить инет и список проксей может смениться
т.е. наглухо дохлые ожить и наеборот помереть тока что живые
как будто не от серваков зависит а от кол-ва их поисков
поэтому решение: с vpn Публичный MTProto Telegram Прокси Список – MTPro.XYZ добавить 20-30-40 проксей удалив глючные(медленные) даже с vpn
а уж без vpn выбирать живущие в данный момент
как минимум каждый раз заходя в выбор проксей - мудачью создаём нагрузку на их железо