Исходя из чего браузер доверяет или нет конкретному сертификату?
У сайта в публичном интернете сертификат должен быть не просто заверен корневым (root'овым), но так же содержать и записи SCT (Signed Certificate Timestamp). Однако, в первую очередь, важно каким из корневых сертификатов заверена цепочка — учитывается откуда именно взялся этот корневой сертификат.
Сценарий №1Самый простой случай — использован сертификат установленный пользователем или администратором устройства. Тогда браузер всего лишь проверяет подписи до такого корневого сертификата, включительно.
Этот сценарий полагается не публичным интернетом, а использованием веб-ресурсов в локальных сетях или специализированных порталов корпоративной инфраструктуры. И потому браузер особо не мудрствует, а ориентируется на те флаги, по которым можно понять, откуда в хранилище сертификатов взялся корневой сертификат.
Сертификаты удостоверяющих центров публичного интернета всегда помечены как предоставленные вендором устройства/системы/платформы — изначально размещёны в централизованном хранилище устройства или операционной системы. А когда пользователь добавляет корневой сертификат какого-либо удостоверяющего центра в это или схожее хранилище, тот помещается в отдельную группу или категорию. Именно таким образом браузер и распознаёт, каким типом корневых сертификатов заверена (подписана) та цепочка сертификатов, которую получил при открытии-загрузке веб-сайта.
Сценарий №2Это когда веб-сайт предъявляет цепочку заверенную «нормальным» корневым сертификатом.
Таким корневым, который из множества изначально размещённого в специализированном хранилище на устройства (сформировано вендором устройства/платформы или операционной системы).
Однако, современный веб-браузер не доверяет специализированному хранилищу и смотрит в своё собственное. Фактически браузер использует эпизодически обновляемый список отозванных сертификатов.
Например, в 2020-2021 годах Правительство Казахстана пыталось внедрить слежку за гражданами, обязывая всех внедрять корневой сертификат на продаваемые устройства и компьютеры. Бывали случае и другого толка, от различных вендоров устройств, ради подглядывания за трафиком с целью сбора данных для рекламы.
В таких раскладах Chrome и остальные на базе Chromium (Vivaldi, Brave & etc.) стремились оградить пользователей и нивелировали эту злонамеренную активность с сертификатами. Т.е. браузер исходит лишь из своей собственный модели доверия к сертификатам, опираясь на своё хранилище, используя системное централизованное лишь на вторичных ролях.
Если веб-браузер убедился, что с корневым сертификатом всё нормально, тогда наступает вторая фаза — а имеются ли SCT (Signed Certificate Timestamp) записи в той цепочке сертификатов, которую предъявляет загружаемый веб-сайт. Если нет двух-трёх записей SCT, то и доверия к сертификату сайта не будет.
Это часть инициативы Certificate Transparency (CT), благодаря которой в современных реалиях удостоверяющие центры не могут выпускать втихоря по несколько сертификатов для одного и того же сайта. Например, исходя из мошеннических побуждений, давления или сговора с правоохранительными, силовыми или правительственными структурами.
Как это работает, в процессе выпуска сертификата удостоверяющий центр обращается к нескольким независимым друг от друга CT-реестрам и регистрирует там факт выдачи конкретного сертификата для конкретного домена — получая от каждого SCT (Signed Certificate Timestamp) запись, которая и добавляется в сертификат.
Владельцы и пользователи онлайн-ресурса могут отслеживать по CT-реестрам факт неожиданной выдачи сертификатов на определённые доменные имена. Собственники CT-реестра не заинтересованы мухлевать и сговариваться с удостоверяющими центрами, поскольку SCT-записи заверяются цифровой подписью CT-реестра. Все записи о выданных сертификатах в CT-реестре являются деревом Меркла — фактически это блокчейн, когда цепочка блоков сшита хеш-суммами.
Выписывая квиточек — SCT (Signed Certificate Timestamp) запись — реестр обязуется включить запись о данном сертификате не моментально, а с некоторой задержкой по времени, порой и до 24 часов.
Свой PKI, без монополий корпорацийИзложенное здесь
и ранее определяет ситуацию, что государствам надо развивать свои веб-браузеры. Поскольку вся эта игра со списками отозванных сертификатов находится прямо в кодовой базе open source того же Chromium и неизвестно как будет использоваться корпорациями (политически ангажированными и весьма одиозными).
На данный момент разнообразие в РФ не блещет и не радует, это или Яндекс или Атом — каждый из которых напичкан супер-плотной интеграцией либо с Яндекс-сервисами, либо ВК-сервисами, соответственно. Нормальному человеку такое сложно вручать, даже при условии использования сугубо лишь для походов по ресурсам государственных услуг, здравоохранения и кредитно финансовых учреждений. В любом случае, придётся держать на устройствах несколько веб-браузеров с разделением обязанностей.
Однако, помимо суеты с веб-браузером так же был поднят и свой Certificate Transparency (CT) реестр, о чём громко заявлял Яндекс в районе 2022 года. Поскольку никакой иностранный не будет принимать данные-записи о выдачи сертификатов заверенных Минцифры РФ и соответственно не будет SCT-квиточки формировать для включения в сертификаты.
А всяких разных Certificate Transparency (CT) реестров должно быть сразу несколько, желательно в разных юрисдикциях, во избежание подозрений в инсинуациях и пустых упрёков. Вероятно работающих не только с российскими удостоверяющими центрами, но и стран БРИКС, СНГ и оставшихся семи миллиардов, в противовес тем, что обслуживают интересы «золотого миллиарда» (население планеты уже более 8 миллиардов).
#
https #
certificate-transparency #
crypto #
криптография #
tls #
PKI #
pki #
chromium #
chrome #
lang_ru @
Russia
