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.)
в будущем авторы прокси обещают сделать ввод других доменов и возможность не пускать клиентов, если они используют другой домен при согласовании подключения.
Для "ввода других доменов" от прокси ничего не требуется. Что вы положите в base64 секрет после 17го байта то и будет передано как домен.
Довольно давно работаю с Erlang. Очень часто сталкивался с ситуацией когда нанимали разработчиков с опытом в других языках но без знания Erlang. Прлсто с желанием его изучить. Обычно довольно быстро вливались. Иногда правда случалось что через какое-то время разочаровывались. Но не так часто.
Есть 2 стороны подключения: одна от телеграм-клиента к прокси, вторая от прокси к серверам телеграм. Обе стороны используют разные форматы пакетов и алгоритмы шифрования.
Клиент-прокси подключение использует 2 "слоя" поверх тех пакетов, которые изображены на картинке в статье — один для шифрования и один для разбивки TCP потока на пакеты:
Самый "внешний" — это потоковый AES_CTR. Ключи шифрования передаются в первом 64-байт пакете при подключении клиента. Так же в этом пакете передаётся (в зашифрованном виде) номер датацентра телеграма, к которому прокси должна подключить клиента и ID протокола следующего слоя.
Протоколов разбивки на пакеты 3: abridged, intermediate, mtp_secure
первые 2 отличаются тем, как кодируется длина пакета. Третий mtp_secure — это тот же mtp_intermediate, но с подмешиванием в каждый пакет 0-3 байт случайных данных (dd-режим).
Для подключения прокси-телеграм сервер используется 3 "слоя" — внешний для шифрования, средний для разбивки потока данных на пакеты и последний для поддкржки мультиплексирования:
Шифрование блочное AES_CBC. Ключ шифрования включает в себя unix timestamp и IP адрес прокси-сервера. Поэтому важно чтоб на прокси были корректно настроены часы и возможны проблемы при работе через NAT.
Слой пакетирования — mtp_full. От abridged и intermediate отличается наличием crc32 контрольной суммы. Слой RPC добавляет поддержку своего рода RPC с небольшим набором команд для управления передачей пакетов, принудительного дисконнекта клиентов и мультиплексирования.
Мультиплексирование вообще очень интересная штука: множество подключений клиент-прокси направляется в одно подключение прокси-телеграм сервер. Это экономит время на подключение, позволяет проксировать больше 63к одновременных подключений и избавляет от проблемы с множеством TIME_WAIT сокетов. Если реализация прокси-сервера её не поддерживает, на достаточно высоких нагрузках будет много проблем на уровне ОС. На данный момент реализовано только в официальной и Erlang версиях.
Небольшое замечание: картинка с описанием формата пакета не имеет отношения к mtproto proxy. То что на картинке это просто mtproto пакет. Mtproto proxy еще 2 слоя поверх этих пакетов добавляет
имею в виду депозиты при аренде квартиры. В статье пишут, что
Ещё один неприятный момент при аренде квартиры — это депозит. Он может составлять до четырёх месячных оплат — это около 50000 NOK.
и я добавил что в Швеции обычно берут депозит в размере с один месяц аренды.
С ипотекой в Швеции пожалуй основная сложность — первый взнос должен быть не менее 15% от стоимости жилья и годовая амортизация должна быть не менее кажется 2% от цены жилья. Так что при подаче заявления в банке оценивают:
1) есть ли у тебя достаточная сумма для первого взноса
3) с твоим текущим уровнем доходов останется ли у тебя достаточно денег для комфортного проживания после выплаты ипотеки даже если процентная ставка вдруг вырастет раза в 2 (тут процентная ставка фиксируется не на весь срок ипотеки а на период от 3 месяцев до 5 лет на ваш выбор)
Но в целом всё выглядит довольно прозрачно и обоснованно
В Эрланге копирование всегда, но с важной оговоркой: бинарные данные размером больше 64 байт не копируются, а хранятся в общей куче и управляются по счётчику ссылок. А в виде бинарных данных в Эрланге принято обрабатывать почти все "данные". Для примера посмотрел на своем приложении:
binary: 709Мб
process: 124Мб
ets (ещё один способ шарить данные между процессами): 118Мб
Т.е. из 1Гб памяти потенциально может быть скопировано при передаче между процессами только 124Мб.
Ну и для копирования данных в Erlang под капотом используется memcpy а не сериализация в строку / json. Плюс собственная сложная система аллокаторов памяти заточенная на такое обращение.
Сокеты между erlang процессами можно передавать, но нужно для этого использовать отдельное API либо "обернуть" сокет в процесс. Тогда вообще никаких ограничений.
Не понял вопрос.
Если вы про python mtprotoproxy, то чем больше вы секретов для одного порта назначите, тем больше будет нагрузка на CPU на установление подключения. Максимальная нагрузка будет если кто-то подключится и отправит 64 байта данных, к которым не один ключ не подойдёт, потому что сервер будет вынужден перепробовать их все.
А что под потоками подразумевается? Трелы ОС в python версии не запускаются вообще, всё однопоточное (asyncio).
Важное различие между официальным прокси и всеми остальными, что официальный мультиплексирует много коннектов клиент-прокси в небольшое количество коннектов прокси-сервер телеграм.
Другие реализации всегда создают пару сокетов.
Когда клиент подключается к mtproto серверу, то он присылает 64байта — данные сессии, зашифрованные этим вот секретом. Если расшифровать эти 64 байта правильным секретом, то там в расшифрованном пакете определённой позиции будет проверочная сумма. Если она не совпала, то нужно пробовать расшифровать следующим ключом. Т.е. в худшем случае придётся много раз расшифровывать, перебирая ключ.
А чего вы опасаетесь? Если боитесь, что перехватят пароль от вашего сервиса прослушивая трафик SOCKS, генерируйте вашим пользователям отдельные пароли для SOCKS, отличные от паролей от сервиса.
Домен
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, а в нем сертификат сервера всегда зашифрован.
Для "ввода других доменов" от прокси ничего не требуется. Что вы положите в base64 секрет после 17го байта то и будет передано как домен.
Блокирование доступа по домену в Erlang прокси уже реализовано https://github.com/seriyps/mtproto_proxy/blob/b6565d23dc2bdafe68587c9b73dd130bb17f019e/src/mtproto_proxy.app.src#L63
Довольно давно работаю с Erlang. Очень часто сталкивался с ситуацией когда нанимали разработчиков с опытом в других языках но без знания Erlang. Прлсто с желанием его изучить. Обычно довольно быстро вливались. Иногда правда случалось что через какое-то время разочаровывались. Но не так часто.
Картинки нет, но на словах могу объяснить.
Есть 2 стороны подключения: одна от телеграм-клиента к прокси, вторая от прокси к серверам телеграм. Обе стороны используют разные форматы пакетов и алгоритмы шифрования.
Клиент-прокси подключение использует 2 "слоя" поверх тех пакетов, которые изображены на картинке в статье — один для шифрования и один для разбивки TCP потока на пакеты:
Самый "внешний" — это потоковый AES_CTR. Ключи шифрования передаются в первом 64-байт пакете при подключении клиента. Так же в этом пакете передаётся (в зашифрованном виде) номер датацентра телеграма, к которому прокси должна подключить клиента и ID протокола следующего слоя.
Протоколов разбивки на пакеты 3: abridged, intermediate, mtp_secure
первые 2 отличаются тем, как кодируется длина пакета. Третий mtp_secure — это тот же mtp_intermediate, но с подмешиванием в каждый пакет 0-3 байт случайных данных (dd-режим).
Для подключения прокси-телеграм сервер используется 3 "слоя" — внешний для шифрования, средний для разбивки потока данных на пакеты и последний для поддкржки мультиплексирования:
Шифрование блочное AES_CBC. Ключ шифрования включает в себя unix timestamp и IP адрес прокси-сервера. Поэтому важно чтоб на прокси были корректно настроены часы и возможны проблемы при работе через NAT.
Слой пакетирования — mtp_full. От abridged и intermediate отличается наличием crc32 контрольной суммы.
Слой RPC добавляет поддержку своего рода RPC с небольшим набором команд для управления передачей пакетов, принудительного дисконнекта клиентов и мультиплексирования.
Мультиплексирование вообще очень интересная штука: множество подключений клиент-прокси направляется в одно подключение прокси-телеграм сервер. Это экономит время на подключение, позволяет проксировать больше 63к одновременных подключений и избавляет от проблемы с множеством TIME_WAIT сокетов. Если реализация прокси-сервера её не поддерживает, на достаточно высоких нагрузках будет много проблем на уровне ОС. На данный момент реализовано только в официальной и Erlang версиях.
Небольшое замечание: картинка с описанием формата пакета не имеет отношения к mtproto proxy. То что на картинке это просто mtproto пакет. Mtproto proxy еще 2 слоя поверх этих пакетов добавляет
да, верно… но думаю для описанного в оригинальной статье случая это не столь важно.
> Хотя в erlang и существует механизм замедления отправителя в случае если обработчик не справляется с обработко
Это выпилили не так давно
Вместо etop рекомендую observer_cli. Гораздо больше возможностей предоставляет
имею в виду депозиты при аренде квартиры. В статье пишут, что
и я добавил что в Швеции обычно берут депозит в размере с один месяц аренды.
С ипотекой в Швеции пожалуй основная сложность — первый взнос должен быть не менее 15% от стоимости жилья и годовая амортизация должна быть не менее кажется 2% от цены жилья. Так что при подаче заявления в банке оценивают:
1) есть ли у тебя достаточная сумма для первого взноса
3) с твоим текущим уровнем доходов останется ли у тебя достаточно денег для комфортного проживания после выплаты ипотеки даже если процентная ставка вдруг вырастет раза в 2 (тут процентная ставка фиксируется не на весь срок ипотеки а на период от 3 месяцев до 5 лет на ваш выбор)
Но в целом всё выглядит довольно прозрачно и обоснованно
Весьма похоже на мой опыт со Швецией. Но депозиты на кавртиру как правило не выше одной стоимости аренды.
У меня в Erlang реализации тоже метрики собираются. Преимущество собственной реализации — можно метрики сделать какие угодно:
В Эрланге копирование всегда, но с важной оговоркой: бинарные данные размером больше 64 байт не копируются, а хранятся в общей куче и управляются по счётчику ссылок. А в виде бинарных данных в Эрланге принято обрабатывать почти все "данные". Для примера посмотрел на своем приложении:
Т.е. из 1Гб памяти потенциально может быть скопировано при передаче между процессами только 124Мб.
Ну и для копирования данных в Erlang под капотом используется memcpy а не сериализация в строку / json. Плюс собственная сложная система аллокаторов памяти заточенная на такое обращение.
Сокеты между erlang процессами можно передавать, но нужно для этого использовать отдельное API либо "обернуть" сокет в процесс. Тогда вообще никаких ограничений.
Не понял вопрос.
Если вы про python mtprotoproxy, то чем больше вы секретов для одного порта назначите, тем больше будет нагрузка на CPU на установление подключения. Максимальная нагрузка будет если кто-то подключится и отправит 64 байта данных, к которым не один ключ не подойдёт, потому что сервер будет вынужден перепробовать их все.
А что под потоками подразумевается? Трелы ОС в python версии не запускаются вообще, всё однопоточное (asyncio).
Важное различие между официальным прокси и всеми остальными, что официальный мультиплексирует много коннектов клиент-прокси в небольшое количество коннектов прокси-сервер телеграм.
Другие реализации всегда создают пару сокетов.
Когда клиент подключается к mtproto серверу, то он присылает 64байта — данные сессии, зашифрованные этим вот секретом. Если расшифровать эти 64 байта правильным секретом, то там в расшифрованном пакете определённой позиции будет проверочная сумма. Если она не совпала, то нужно пробовать расшифровать следующим ключом. Т.е. в худшем случае придётся много раз расшифровывать, перебирая ключ.
А чего вы опасаетесь? Если боитесь, что перехватят пароль от вашего сервиса прослушивая трафик SOCKS, генерируйте вашим пользователям отдельные пароли для SOCKS, отличные от паролей от сервиса.