Откуда этот конфиг? [Debian/Ubuntu]

Ansible не решит части проблем, если при апдейте системы приползёт новый системный скрипт, который внезапно добавит или изменит конфиг, который до этого Ansible вообще не трогал. Но etcd/consul выглядит для конфигов более удобным, чем Ансибл, хотя проблемы остаются те же, все системные конфиги в него не запихаешь. (Как девелопер сейчас смотрю на эту кухню более со стороны)

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Про эксперимент с TOM Skype слышали? Так что национальный антивирусник, сливающий данные юзера и что он пишет на клавиатуре — уже тоже не будет новым :)

Откуда этот конфиг? [Debian/Ubuntu]

Эх, когда же будут по дефолту конфиги по типу git, чтобы было ясно, кто, откуда, когда и какую строчку. Сохранил как шпаргалку, так как часто подобное приходилось делать в RPM-based.

оператор ЭВМ

Вспомнил свои корочки оператора ЭВМ на втором курсе универа, вытер скупую слезу.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

А самое интересное как раз там, может «сервер» вернёт 3DES/Blowfish… Так же интересно, как он среагирует если его послать на недоверенный сертификат, возможно еще что и удостоверит.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Огромная вероятность, что прохачат. А еще один больной момент — что именно будет вытаскиваться с этого plaintext траффика и куда логироваться — слить или использовать эти данные соблазн будет просто огромен — а ведь, как я понимаю, это не прописано официально ни в каком местном законе. Тут даже закон Яровой померк.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

CDN да, но по той практике что я вижу с VPN, блочат основные домены (например facebook.com) а не их CDN с картинками и видео. Ну а Cloudflare и другой domain-fronting это и есть MITM сам по себе, надо просто закон подписать, чтобы они держали CDN point of presence в стране назначения и все дела.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Мне тоже видится эта затея бесполезной, но немного по другой причине, даже для IP к которым подключились без SNI, делается параллельно скан через «openssl s_client -connect» и сервер радостно отдаёт свой CN и сертификат, который замечательно сохраняется в map'e FQDN-IP, и тут же можно дропать задержанное соединение от юзера. Вот пока это в корне не изменится, в отсутствии или шифровании SNI смысла нет. Такой скан конечно не работает там где на одном IP много доменов, но такие на грани погрешности и они обычно цензоров не интересуют.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Это был бы повод для шикарного поста, если бы оно это пропустило и заверило.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Ну что драфт это ясно, просто cloudflare уже с ним работает. И во-вторых, SNI это необязательное расширение, TLS работает и без него. Если на одном IP не хостятся несколько доменов, то он и не нужен для балансировки на правильные бэкенды. Видны подвижки чтобы скрыть из TLS максимум открытых данных и процесс с тем же cloudflare уже пошёл.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Те MITM что я видел генерят и кэшируют. Хранят недолго, тк ключ короткий (генерить надо быстро). Если используется ограниченный список для MITM как в этом случае, то возможны оба подхода. Я бы всегда выбирал короткоживущие, если их вытащат с прокси, то окно применения будет минимальным.
Разница RSA->/EC/DHE самая главная в том, что ключи эфемеральные если MITM не делался в этот момент и получив RSA pkey постфактум расшифровать сессии не получится. А с RSA можно будет восстановить все записанные ранее сессии. По CPU всё верно, обычный DH так и есть, на эллиптических кривых быстрее.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Я мельком глянул на тестовый сайт этого сертификата и если не ошибаюсь там не увидел Intermediate CA. Технически это возможно, да. Но меняет только срок уязвиомсти. Даже если эти сертификаты сделают Intermediate CA и валидными несколько месяцев, у админов этих проксей соблазн будет огромен. Плюс эти прокси будут генерить логи с какими-то частями расшифрованных данных для последующего анализа.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

А ведь цель такого проксирования будет — вести логи для последующего анализа… Кто знает что будет в этих логах и где они будут храниться… (как-то вспомнился внезапно закон Яровой и параллели с этим)

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Видимо имелось в виду, что с RSA в наше время происходит только verify, а не дешифрование чего-либо (так как море известных padding oracle атак на шифрование RSA). А MITM прокси еще и подписывать надо на лету. Вот подписывание действительно сильно дороже верификации и поэтому сгенерённые на MITM сертификаты обычно кэшируют. По этой же причине на проксе будет короткоживущий сертификат с коротким ключом.

А тех, кто в наше время сесионные ключи шифрования через ассиметричное шифрование RSA создаёт надо сдавать на опыты. Как раз хорошая статья недавно попадалась blog.trailofbits.com/2019/07/08/fuck-rsa. Я уже сто лет не вижу ничего кроме E/C/DHE для сессионных ключей.

                  sign    verify    sign/s verify/s
rsa  512 bits 0.000046s 0.000003s  21622.4 338579.6
rsa 1024 bits 0.000101s 0.000006s   9889.4 157314.6
rsa 2048 bits 0.000663s 0.000022s   1509.4  45480.0
rsa 3072 bits 0.002180s 0.000043s    458.8  23342.1
rsa 4096 bits 0.004457s 0.000071s    224.4  14053.0
rsa 7680 bits 0.046729s 0.000232s     21.4   4313.8
rsa 15360 bits 0.218085s 0.000918s      4.6   1089.1

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Всё растёт, всё развивается. Почитаю что на этот раз придумали, спасибо

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Значит не хватило ума у них построить соотношение FQDN<->IP для тех хостов, где не поддерживается мультихостинг доменов. Что (имхо) косвенно говорит о качестве поделки. Хосты с ESNI будут пропускать.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Шо, правда? А мужики из Cloudflare-то не знают :) /sarcasm off Может оно и не вошло в финальный стандарт (не проверял если честно еще), но уже используется. tools.ietf.org/html/draft-ietf-tls-esni-03 (и да, я знаю, что это extension, но он для TLS1.3)

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Для этого гуглы и прочие придумали certificate pinning. Подозреваю что прецеденты были уже.

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Интересно насколько продвинута прокся, ведь по TLS1.3 SNI тоже пойдёт в шифрованном виде. Если TLS установить на IP фейсбука без SNI, что отдаёт?

openssl s_client -connect 31.13.93.35:443

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Именно так всё и происходит, TLS MITM прокси получает из SNI домен на который направляется пользователь, на лету генерит липовый сертификат на этот домен и подписывает его с помощью ключа Root CA, таким образом выстраивая цепочку доверия. Затем получает от юзера чистый незамутнённый шифрованием HTTP, и сам прокси создаёт второе подключение по реальному HTTPS уже до реального домена. Туда и отправляется HTTP полученный от юзера. Чужие приватные ключи оно получить не может.

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

Готовьтесь и вы, россияне, к MITM в лице государства, как это стало в Казахстане

Тут даже похоже, что это не толпа, а отдельная группа людей с какими-то своими интересами. В любом случае это меня удивило и (пользуясь случаем) спасибо тем кто это поправил. Надеюсь мои комменты по процедурам CA были кому-то полезны.