Ну как бы… Сейчас уже "всё интернет-сообщество" признало, что TCP+TLS1.2 не очень-то подходит для современных реалий (мобильные устройства, частые подключения-отключения, смена IP). Из за этого сделали TLS1.3 и HTTP/3 + QUIC на подходе.
Мессенджеры в этом плане первыми начали с такими проблемами сталкиваться. Делали бы telegram в 2019м — наверное сделали бы на TLS1.3 или QUIC (в статье же писали, что они UDP тоже пытались написать, но не осилили).
это не переизобретение. У него только одна цель — выглядеть как TLS на проводе (для маскировки). Т.к. одно дело если DPI видит поток байт ни на что не похожий (что подозрительно) и другое — валидный http/2 TLS.
В JS прокси только один протокол реализован (нет randomized протокола, нет fake-TLS), нет мультиплексирования, он подключается к серверам предназначенным для подключения telegram клиентов, а не прокси-серверов (т.е. не работают promoted channels). Несрванимые вещи...
1) https://habr.com/ru/post/461171/#comment_20497965
2) Всё-же замечу, что текущие реализации fake-TLS proxy деланы волонтёрами методом реверс-инженеринга. Возможно в официальном это будет как-то иначе решено
Раскодируете base64 секрет, берете первые 17 байт из того что получилось — это и есть сам секрет. Потом к ним в конец дописываете любой домен и кодируете обратно в base64.
В клиенте есть, но прокси тоже должен ответить 0x0304 чтобы сессия выглядела валидной. Плюс, опять же, сертификат должен быть чем-то хотя-бы декодируемым в X.509.
Не знаю, запустил wireshark, дернул страничку своего сайта через TLSv1.3 + HTTP/2 — пакеты такие же, как у телеграма. Нет в ServerHello никаких 0x0304, нет X.509 сертификатов.
Наверное если активно пытаться по https подключиться, то разница будет заметна. Но в пассивном режиме не вижу разницы.
legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.
(See Appendix D for details about backward compatibility.)
Ну как бы… Сейчас уже "всё интернет-сообщество" признало, что TCP+TLS1.2 не очень-то подходит для современных реалий (мобильные устройства, частые подключения-отключения, смена IP). Из за этого сделали TLS1.3 и HTTP/3 + QUIC на подходе.
Мессенджеры в этом плане первыми начали с такими проблемами сталкиваться. Делали бы telegram в 2019м — наверное сделали бы на TLS1.3 или QUIC (в статье же писали, что они UDP тоже пытались написать, но не осилили).
это не переизобретение. У него только одна цель — выглядеть как TLS на проводе (для маскировки). Т.к. одно дело если DPI видит поток байт ни на что не похожий (что подозрительно) и другое — валидный http/2 TLS.
Потребителям, наверное, ничего. Для telegram — отсутствие контроля над ними.
В JS прокси только один протокол реализован (нет randomized протокола, нет fake-TLS), нет мультиплексирования, он подключается к серверам предназначенным для подключения telegram клиентов, а не прокси-серверов (т.е. не работают promoted channels). Несрванимые вещи...
Я когда дописывал Erlang реализацию mtproto proxy часто туда заглядывал. Без него было бы на порядок сложнее, так что спасибо, да
Насколько я слышал, Android выкладывают с задержкой для того чтоб форки не набирали излишней популярности
как я понимаю CertificateСhain едет в
ApplicationDataфрейме? У меня, как и в python прокси, первый ApplicationData фрейм генерится как случайные данные случайной длины от 0 до 256:https://github.com/seriyps/mtproto_proxy/blob/5e601bce3e19cdc3d3f2b77313e3ee57b8dce482/src/mtp_fake_tls.erl#L109
https://github.com/alexbers/mtprotoproxy/blob/e43ae9991102c8471c7f2436df63f7d64906940c/mtprotoproxy.py#L839
Возможно стоит увеличить размер?
Как я понимаю, засовывать туда реальный сертификат смысла большого нет, т.к. он зашифрован и пассивным анализом трафика его не расшифровать?
wireshark.org
Хм, да, выправы! Спасибо!
Поправил в Erlang версии: https://github.com/seriyps/mtproto_proxy/commit/5e601bce3e19cdc3d3f2b77313e3ee57b8dce482
1) https://habr.com/ru/post/461171/#comment_20497965
2) Всё-же замечу, что текущие реализации fake-TLS proxy деланы волонтёрами методом реверс-инженеринга. Возможно в официальном это будет как-то иначе решено
Раскодируете base64 секрет, берете первые 17 байт из того что получилось — это и есть сам секрет. Потом к ним в конец дописываете любой домен и кодируете обратно в base64.
Но имейте в виду что, например, в Erlang прокси есть опция ограничивающая домены с которыми можно подключаться .
upd: разметка поехала, не знаю как поправить
Ну для этого придётся полноценный TLS реализовывать. То что в mtproto proxy — хоть и маскируется под TLS 1.3, но внутри совсем по другому устроено.
Не знаю, запустил wireshark, дернул страничку своего сайта через TLSv1.3 + HTTP/2 — пакеты такие же, как у телеграма. Нет в ServerHello никаких 0x0304, нет X.509 сертификатов.
Наверное если активно пытаться по https подключиться, то разница будет заметна. Но в пассивном режиме не вижу разницы.
URL в TLS mtproto proxy протоколе не используется
Домен
google.comберется из секрета. Его можно на что угодно заменить.https://tools.ietf.org/html/rfc8446#section-4.1.2
legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.
(See Appendix D for details about backward compatibility.)
Нет, телеграм маскируется под TLS 1.3
Это TLSv1.3.
Ну да, в текущих реализациях прокси серверов реакция на не-телеграмный tls не такая же как у реального https. Но это поправимо.
Telegram притворяется TLSv1.3, а в нем сертификат сервера всегда зашифрован.