Китай и Иран используют replay-атаки для борьбы с Telegram

В баг-трекерах популярных MTProxy-серверов mtg ^[1] и mtprotoproxy ^[2] появились сообщения, о том что в Иране и Китае надзорные органы научились каким-то образом выявлять и блокировать телеграм-прокси, даже испольщующие рандомизацию длины пакета (dd-префикс).
В итоге выяснилась занятная история: для выявления прокси-серверов MTProxy злоумышленники использовали replay-атаки.

Атака повторного воспроизведения (replay) — атака на систему аутентификации путём записи и последующего воспроизведения ранее посланных корректных сообщений или их частей

(wiki ^[3])

Пакеты установления соединения с proxy «записываются» третьим лицом, и через некоторое время производится попытка подключения, при этом используется сохраненный заголовок пакета вместе с «испорченными» данными.
Если посмотреть на структуру пакета MTProxy
(картинка взята вот из этой ^[4] статьи)

то получается примерно представить, как оно может работать:
прокси-сервер анализирует заголовок пакета, признает его валидным, и отправляет дальше непосредственно на сервера Telegram. Сервера Telegram принимают пакет, но отвечают на него сообщением об ошибке, которое пересылается прокси-сервером обратно, и детектировать его можно просто по длине пакета (пакеты с сообщение об ошибке гораздо короче чем нормальные).
На основании этого и происходит блокировка адреса сервера.
Разработчики обоих прокси-серверов уже выпустили обновления. При соединении выполняется проверка, что коннектов с таким auth_key_id (по сути дела представляющим соой 64-битное случайное число) еще не было:
github.com/alexbers/mtprotoproxy/commit/4cae6290b9529485125366771005460309a835b5 ^[5]
github.com/9seconds/mtg/commit/33852ca4818c365778edccb7441a11decff90009 ^[6]

В дополнение ко всему, несколько дней назад в российских сетевых сообществах и телеграм-каналах появилась весьма занимательная информация, что наш родной РКН начал использовать открытые прокси для проверки публичных mtproxy-серверов. С одной стороны, это вполне логичный шаг, т.к. со своих адресов заниматься такими проверками они не хотят или не могут, потому что их диапазоны подсетей станут быстро известны владельцам серверов, а с другой стороны, во многих случаях «публичные прокси» представляют собой взломанные soho-роутеры, что делает ситуацию весьма пикантной.
Подробную статью об этом ^[7]можно прочитать на tjournal.

Энтузиасты уже разработали скрипт ^[8], автоматически получающий актуальный список открытых прокси и применяющий правила ipset для эффективной фильтрации адресов из этого списка:
В дополнению к скрипту идет краткая инструкция ^[9] по его использованию, написанная очень живым языком.

Автор: Whuthering

Источник ^[10]