Pull to refresh
128
0
Сергей @seriyPS

backend

Send message

Иран
...
Во время массовых волнений 2017 года был заблокирован Telegram, но позже опала была снята, поскольку мессенджер использовали 40 миллионов человек и запрет Телеграма грозил уже экономике страны.

Телеграм в Иране всё ещё заблокирован. В 2019м вроде бы отключали вообще весь интернет на несколько дней, что было в 17м не знаю. Но телеграм уже очень давно заблокирован; многие всё равно пользуются через mtproto proxy (которые тоже блокируют).

является ли совпадением релиз нашей первой игры Battle Prime и персональная юридическая атака на наших сотрудников

Да уж наверняка не совпадение. Правда, не спец по мобильным играм… Этот их шутер Battle Prime может конкурировать с WoT Blitz?


приобретён компанией Wargaming в качестве Open Source технологии, распространяемой по лицензии BSD3, и с 2014 по 2018 продолжал разрабатываться на базе СООО «Гейм Стрим» с ведома всех уполномоченных и ответственных лиц в Wargaming по той же BSD3 лицензии

Как я понимаю, то, что движок был изначально под BSD3 не мешает компании сделать свой приватный форк и запретить разработчикам публиковать изменения из этого форка. Вопрос в том согласована была публикация форка или нет...

Дичь какая-то. Посмотрел свои выписки — 27% получилось разница между заявленной ЗП и той, которую на руки получаю (это предварительно, в конце года могут быть корректировки).

Видимо недостаточно. Или у вас есть другие объяснения?

Из того что я читал — основная проблема SCTP в том, что его не понимает сетевое оборудование (в отличие от TCP и UDP).


В разработке HTTP/3 + QUIC не только гугл участвует (Mozilla, Cloudflare, Netflix), видимо не у одного него есть к TCP + TLS претензии.

Ну как бы… Сейчас уже "всё интернет-сообщество" признало, что 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
Возможно стоит увеличить размер?


Как я понимаю, засовывать туда реальный сертификат смысла большого нет, т.к. он зашифрован и пассивным анализом трафика его не расшифровать?

Хм, да, выправы! Спасибо!


Поправил в Erlang версии: https://github.com/seriyps/mtproto_proxy/commit/5e601bce3e19cdc3d3f2b77313e3ee57b8dce482


image

1) https://habr.com/ru/post/461171/#comment_20497965
2) Всё-же замечу, что текущие реализации fake-TLS proxy деланы волонтёрами методом реверс-инженеринга. Возможно в официальном это будет как-то иначе решено

$ base64 -d <<< 7gAAAAAAAAAAAAAAAAAAAABnb29nbGUuY29t | hexdump -C
00000000  ee 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 67 6f 6f 67 6c 65 2e  63 6f 6d                 |.google.com|

Раскодируете base64 секрет, берете первые 17 байт из того что получилось — это и есть сам секрет. Потом к ним в конец дописываете любой домен и кодируете обратно в base64.


Но имейте в виду что, например, в Erlang прокси есть опция ограничивающая домены с которыми можно подключаться .
upd: разметка поехала, не знаю как поправить

Ну для этого придётся полноценный TLS реализовывать. То что в mtproto proxy — хоть и маскируется под TLS 1.3, но внутри совсем по другому устроено.

В клиенте есть, но прокси тоже должен ответить 0x0304 чтобы сессия выглядела валидной. Плюс, опять же, сертификат должен быть чем-то хотя-бы декодируемым в X.509.

Не знаю, запустил wireshark, дернул страничку своего сайта через TLSv1.3 + HTTP/2 — пакеты такие же, как у телеграма. Нет в ServerHello никаких 0x0304, нет X.509 сертификатов.


Наверное если активно пытаться по https подключиться, то разница будет заметна. Но в пассивном режиме не вижу разницы.

URL в TLS mtproto proxy протоколе не используется

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity