Часть 3: почему Russian Trusted Root CA не доверяет никто Вопрос задают регулярно и обычно с подтекстом — мол, политика, санкции, русофобия. Отвечаю по порядку и начну со скучного. Сертификат министерства деградации никто и не отвергал. Он не проходил процедуру. Совсем. Попадание в корневое хранилище — не голосование и не решение по симпатиям. У Mozilla вся кухня публичная, в багтрекере: заявка, выложенные политики CP/CPS, соответствие Baseline Requirements, работа с Certificate Transparency, проверка домена из нескольких географических точек, публичное обсуждение, где посторонние люди месяцами ковыряют вашу документацию. И сверху — независимый аудит WebTrust или ETSI за весь период работы. На аудите всё и заканчивается. Аудиторы WebTrust аккредитованы через CPA Canada, ETSI — через европейские органы аккредитации. Государственный удостоверяющий центр из России такого аудита не получит физически. А без него заявку даже не начнут читать. Замкнутый круг, к чьей-либо доброй воле отношения не имеющий. Теперь по существу. Допустим, аудит волшебным образом появился. Дальше начинается оценка рисков, и она короткая. Корень в хранилище — это возможность выпустить действующий сертификат на любой домен планеты. Не на свои сайты. На любые. Корневые программы задают ровно один вопрос: какова вероятность, что этот центр выпустит сертификат не по своей воле, а по указанию? Для центра, который принадлежит государству, где СОРМ прописан в законе, а ТСПУ уже стоят на сетях операторов, ответ считается в уме. Точки перехвата развёрнуты. Не хватает одной бумажки, которая сделает перехват невидимым для браузера. И это не умозрительная конструкция, а живой прецедент по соседству. Казахстан требовал от абонентов ставить государственный корень в 2015, 2019 и 2020 годах. В 2019-м его действительно применили — перехватывали трафик к Facebook, Google и Twitter. После чего Chrome, Firefox и Safari внесли этот сертификат в чёрный список прямо в код браузера. То есть он перестал работать даже у тех, кто поставил его сам. Про русофобию. Из хранилищ вычищали всех подряд, без оглядки на флаг: голландцев, турок, китайцев, американцев, канадцев (см. предыдущую часть). Разница в одном: ни один из них не был государственным центром страны с законодательно обязательной прослушкой. Порог тут объективно выше, и это следствие модели угроз, а не риторики. С самими сертификатами, к слову, всё в порядке. Обычный RSA, обычный X.509, никакого ГОСТа. Проблема не в криптографии. Проблема исключительно в том, кто за них ручается. Спойлер: НИКТО Итог на сегодня: корня нет в Chrome, Firefox, Safari и Edge. Доверяют ему Яндекс.Браузер и Атом, куда его вшили разработчики, плюс корпоративные контуры, куда его раскатали групповыми политиками. Деталь, которую все путают: он не заблокирован, как казахстанский. Он просто отсутствует. Разница принципиальная — установленный вручную, он работает. Вот про это вручную и будет последняя часть.

В чем проблема вот этих самых сертификатов от министерства деградации, я попробую максимально простыми словами. Коротко не получилось — получилось серия постов Кто выдаёт замочек в браузере. Часть 1: цепочка доверия Начнём с того, что шифрование — простая часть задачи. Договориться о ключах два узла умеют давно и без посторонней помощи. Сложная часть другая: как убедиться, что на том конце провода действительно ваш банк, а не бодрый юноша, вклинившийся посередине. Для этого и придуман сертификат. По сути — заверенная кем-то справка: публичный ключ такой-то принадлежит домену такому-то. Всё. Вся мировая система TLS растёт из одного вопроса — чью подпись на этой справке мы согласны принимать. Устроено матрёшкой. Есть удостоверяющий центр (CA), у него корневой ключ — лежит в железном модуле, достаётся по регламенту, под видеозапись, в присутствии нескольких человек с разными ключами от сейфа. Корнем подписывают промежуточные сертификаты, промежуточными — миллионы сертификатов для сайтов. Браузер получает сертификат сайта, идёт вверх по цепочке и упирается в корень. Корень в списке доверенных — замочек. Нет — жёлтый экран. А теперь интересное: власть тут не у центров сертификации. Власть у тех, кто ведёт список корней. Список корней — это Mozilla (её хранилищем де-факто пользуется весь Linux, curl и полмира сборок), Microsoft, Apple и Google (у Chrome с 2022 года своя программа). Четыре организации решают, чьей подписи доверяет планета. Правила пишет CA/Browser Forum — добровольный клуб центров и браузеров. Ни ООН, ни ITU, ни одного государственного регулятора. Документ называется Baseline Requirements, соблюдение проверяется ежегодным аудитом WebTrust или ETSI. Частная лавочка с драконовскими внутренними порядками — и, что забавно, работает она лучше многих межправительственных конструкций. Проверок бывает три вида. DV — подтверждается только контроль над доменом (положи файл по нужному адресу или заведи TXT-запись в DNS). OV — плюс проверка юрлица. EV — расширенная проверка компании, та самая, что когда-то рисовала зелёную плашку с названием фирмы. Плашку убрали в 2019-м: выяснилось, что на поведение людей она не влияет никак. Осталась дорогая формальность. Сегодня почти всё — это DV. Let's Encrypt с протоколом ACME сделал выдачу бесплатной и полностью автоматической, и рынок платных DV-сертификатов тихо скукожился. В следующей части — что бывает, когда удостоверяющий центр оступается. Спойлер: бывает быстро и больно.

Файлы куки Разные сайты пишут, мол, «мы используем файлы куки». Да это не файлы куки, а просто куки! Ну да, на диске куки хранятся в файлах, — ну так на диске всё хранится в файлах, даже сам браузер — это тоже файлы! Вы же не пишете «обновите ваши файлы браузер до последней версии». Куки при этом могут храниться в отдельных файлах каждая, в одном файле все, в кастомной базе данных или как угодно ещё, и это вообще не важно. Более того, даже если вы точно знаете, что конкретный браузер, с которым я к вам зашёл, хранит куки в виде отдельных файлов, всё равно вы не «используем файлы куки». Файлы на моём диске-то вы всё равно не видите и не используете никак. Это мой файлы браузер читает свои файлы куки и отправляет вам сами эти куки, а не файлы, чтобы ваши файлы веб-сервер могли что-то с ними сделать.