В баг-трекерах популярных MTProxy-серверов mtg и mtprotoproxy появились сообщения о том, что в Иране и Китае надзорные органы научились каким-то образом выявлять и блокировать телеграм-прокси, даже испольщующие рандомизацию длины пакета (dd-префикс).
В итоге выяснилась занятная история: для выявления прокси-серверов MTProxy злоумышленники использовали replay-атаки.
Пакеты установления соединения с proxy «записываются» третьим лицом, и через некоторое время производится попытка подключения, при этом используется сохраненный заголовок пакета вместе с «испорченными» данными.
Если посмотреть на структуру пакета MTProxy
(картинка взята вот из этой статьи)
то получается примерно представить, как оно может работать:
прокси-сервер анализирует заголовок пакета, признает его валидным, и отправляет дальше непосредственно на сервера Telegram. Сервера Telegram принимают пакет, но отвечают на него сообщением об ошибке, которое пересылается прокси-сервером обратно, и детектировать его можно просто по длине пакета (пакеты с сообщение об ошибке гораздо короче чем нормальные).
На основании этого и происходит блокировка адреса сервера.
Разработчики обоих прокси-серверов уже выпустили обновления. При соединении выполняется проверка, что коннектов с таким auth_key_id (по сути дела представляющим собой 64-битное случайное число) еще не было:
github.com/alexbers/mtprotoproxy/commit/4cae6290b9529485125366771005460309a835b5
github.com/9seconds/mtg/commit/33852ca4818c365778edccb7441a11decff90009
В дополнение ко всему, несколько дней назад в российских сетевых сообществах и телеграм-каналах появилась весьма занимательная информация, что наш родной РКН начал использовать открытые прокси для проверки публичных mtproxy-серверов. С одной стороны, это вполне логичный шаг, т.к. со своих адресов заниматься такими проверками они не хотят или не могут, потому что их диапазоны подсетей станут быстро известны владельцам серверов, а с другой стороны, во многих случаях «публичные прокси» представляют собой взломанные soho-роутеры, что делает ситуацию весьма пикантной.
Подробную статью об этом можно прочитать на tjournal.
Энтузиасты уже разработали скрипт, автоматически получающий актуальный список открытых прокси и применяющий правила ipset для эффективной фильтрации адресов из этого списка.
В дополнению к скрипту идет краткая инструкция по его использованию, написанная очень живым и воодушевляющим языком.
В итоге выяснилась занятная история: для выявления прокси-серверов MTProxy злоумышленники использовали replay-атаки.
Атака повторного воспроизведения (replay) — атака на систему аутентификации путём записи и последующего воспроизведения ранее посланных корректных сообщений или их частей(wiki)
Пакеты установления соединения с proxy «записываются» третьим лицом, и через некоторое время производится попытка подключения, при этом используется сохраненный заголовок пакета вместе с «испорченными» данными.
Если посмотреть на структуру пакета MTProxy
(картинка взята вот из этой статьи)то получается примерно представить, как оно может работать:
прокси-сервер анализирует заголовок пакета, признает его валидным, и отправляет дальше непосредственно на сервера Telegram. Сервера Telegram принимают пакет, но отвечают на него сообщением об ошибке, которое пересылается прокси-сервером обратно, и детектировать его можно просто по длине пакета (пакеты с сообщение об ошибке гораздо короче чем нормальные).
На основании этого и происходит блокировка адреса сервера.
Разработчики обоих прокси-серверов уже выпустили обновления. При соединении выполняется проверка, что коннектов с таким auth_key_id (по сути дела представляющим собой 64-битное случайное число) еще не было:
github.com/alexbers/mtprotoproxy/commit/4cae6290b9529485125366771005460309a835b5
github.com/9seconds/mtg/commit/33852ca4818c365778edccb7441a11decff90009
В дополнение ко всему, несколько дней назад в российских сетевых сообществах и телеграм-каналах появилась весьма занимательная информация, что наш родной РКН начал использовать открытые прокси для проверки публичных mtproxy-серверов. С одной стороны, это вполне логичный шаг, т.к. со своих адресов заниматься такими проверками они не хотят или не могут, потому что их диапазоны подсетей станут быстро известны владельцам серверов, а с другой стороны, во многих случаях «публичные прокси» представляют собой взломанные soho-роутеры, что делает ситуацию весьма пикантной.
Подробную статью об этом можно прочитать на tjournal.
Энтузиасты уже разработали скрипт, автоматически получающий актуальный список открытых прокси и применяющий правила ipset для эффективной фильтрации адресов из этого списка.
В дополнению к скрипту идет краткая инструкция по его использованию, написанная очень живым и воодушевляющим языком.
