Иран ... Во время массовых волнений 2017 года был заблокирован Telegram, но позже опала была снята, поскольку мессенджер использовали 40 миллионов человек и запрет Телеграма грозил уже экономике страны.
Телеграм в Иране всё ещё заблокирован. В 2019м вроде бы отключали вообще весь интернет на несколько дней, что было в 17м не знаю. Но телеграм уже очень давно заблокирован; многие всё равно пользуются через mtproto proxy (которые тоже блокируют).
является ли совпадением релиз нашей первой игры Battle Prime и персональная юридическая атака на наших сотрудников
Да уж наверняка не совпадение. Правда, не спец по мобильным играм… Этот их шутер Battle Prime может конкурировать с WoT Blitz?
приобретён компанией Wargaming в качестве Open Source технологии, распространяемой по лицензии BSD3, и с 2014 по 2018 продолжал разрабатываться на базе СООО «Гейм Стрим» с ведома всех уполномоченных и ответственных лиц в Wargaming по той же BSD3 лицензии
Как я понимаю, то, что движок был изначально под BSD3 не мешает компании сделать свой приватный форк и запретить разработчикам публиковать изменения из этого форка. Вопрос в том согласована была публикация форка или нет...
Дичь какая-то. Посмотрел свои выписки — 27% получилось разница между заявленной ЗП и той, которую на руки получаю (это предварительно, в конце года могут быть корректировки).
Ну как бы… Сейчас уже "всё интернет-сообщество" признало, что 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 подключиться, то разница будет заметна. Но в пассивном режиме не вижу разницы.
Телеграм в Иране всё ещё заблокирован. В 2019м вроде бы отключали вообще весь интернет на несколько дней, что было в 17м не знаю. Но телеграм уже очень давно заблокирован; многие всё равно пользуются через mtproto proxy (которые тоже блокируют).
Да уж наверняка не совпадение. Правда, не спец по мобильным играм… Этот их шутер Battle Prime может конкурировать с WoT Blitz?
Как я понимаю, то, что движок был изначально под BSD3 не мешает компании сделать свой приватный форк и запретить разработчикам публиковать изменения из этого форка. Вопрос в том согласована была публикация форка или нет...
https://habr.com/ru/company/moikrug/blog/479688/#comment_20991074 да, уже заметили
Дичь какая-то. Посмотрел свои выписки — 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
Возможно стоит увеличить размер?
Как я понимаю, засовывать туда реальный сертификат смысла большого нет, т.к. он зашифрован и пассивным анализом трафика его не расшифровать?
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 протоколе не используется