Компания Mozilla о начале тестирования в ночных сборках Firefox нового механизма определения отозванных сертификатов — . CRLite позволяет организовать эффективную проверку отзыва сертификатов по базе данных, размещаемой на системе пользователя. Развиваемая в Mozilla реализация CRLite под свободной лицензией MPL 2.0. Код для генерации БД и серверные компоненты написаны на и Go. Добавленные в Firefox клиентские части для чтения данных из БД на языке Rust.
Применяемая до сих пор поверка сертификатов с привлечением внешних служб на базе протокола (Online Certificate Status Protocol) требует наличия гарантированного сетевого доступа, приводит к возникновению ощутимой задержки на обработку запроса (в среднем 350мс) и имеет проблемы с обеспечением конфиденциальности (отвечающие на запросы серверы OCSP получают сведения о конкретных сертификатах, по которым можно судить о том, какие сайты открывает пользователь). Существует также возможность локальной проверки по спискам (Certificate Revocation List), но минусом такого метода является очень большой размер загружаемых данных — в настоящее время БД отозванных сертификатов занимает около 300 МБ и её рост продолжается.
Для блокирования скомпрометированных и отозванных удостоверяющими центрами сертификатов в Firefox с 2015 года используется централизованный чёрный список в сочетании с обращением к сервису для определения возможной вредоносной активности. OneCRL, как и в Chrome, выступает промежуточным звеном, который агрегирует CRL-списки от удостоверяющих центров и предоставляет единый централизованный OCSP-сервис для проверки отозванных сертификатов, дающий возможность не отправлять запросы непосредственно в удостоверяющие центры. Несмотря на большую работу по повышению надёжности сервиса online-проверки сертификатов, данные телеметрии показывают, что более 7% запросов OCSP завершается таймаутом (несколько лет назад этот показатель составлял 15%).
По умолчанию, в случае невозможности осуществить проверку через OCSP, браузер считает сертификат корректным. Сервис может быть недоступен как из-за сетевых проблем и ограничений внутренних сетях, так и блокирован атакующими — для обхода проверки OCSP в ходе MITM-атаки достаточно просто заблокировать доступ к сервису проверки. Частично для предотвращения подобных атак реализована техника , позволяющая трактовать ошибку обращения по OCSP или недоступность OCSP как проблему с сертификатом, но данная возможность опциональна и требует специального оформления сертификата.
CRLite позволяет свести полные сведения обо всех отозванных сертификатах в легко обновляемую структуру, размером всего 1 MB, что даёт возможность хранить полную базу CRL на стороне клиента.
Браузер сможет ежедневно синхронизировать свою копию данных об отозванных сертификатах, и эта БД будет доступна при любых условиях.
CRLite объединяет сведения из , публичного лога всех выданных и отозванных сертификатов, и результатов сканирования сертификатов в интернете (собираются различные CRL-списки удостоверяющих центров и агрегируется информация о всех известных сертификатах). Данные упаковываются с использованием каскадных , вероятностной структуры, допускающей ложное определение отсутствующего элемента, но исключающей пропуск существующего элемента (т.е. с определённой вероятностью возможно ложное срабатывание на корректный сертификат, но отозванные сертификаты гарантированно будут выявлены).
Для исключения ложных срабатываний в CRLite введены дополнительные корректирующие уровни фильтра. После генерации структуры осуществляется перебор всех исходных записей и определение возникших ложных срабатываний. По результатам данной проверки создаётся дополнительная структура, которая каскадно накладывается на первую и корректирует возникшие ложные срабатывания. Операция повторяется до тех пор, пока ложные срабатывания при контрольной проверке не будут полностью исключены. Обычно для полного покрытия всех данных достаточно создания 7-10 слоёв. Так как состояние БД из-за периодической синхронизации немного отстаёт от актуального состояния CRL, проверка новых сертификатов, выписанных после последнего обновления БД CRLite, осуществляется при помощи протокола OCSP, в том числе используя технику (заверенный удостоверяющим центром ответ OCSP передаётся обслуживающим сайт сервером при согласовании TLS-соединения).
При помощи фильтров Блума декабрьский срез сведений из WebPKI, охватывающий 100 млн активных сертификатов и 750 тысяч отозванных сертификатов, удалось упаковать в структуру, размером 1.3 MB. Процесс генерации структуры достаточно ресурсоёмкий, но он выполняется на сервере Mozilla и пользователю отдаётся уже готовое обновление. Например, в бинарной форме используемые при генерации исходные данные требуют около 16 ГБ памяти при хранении в СУБД Redis, а в шестнадцатеричном виде дамп всех серийных номеров сертификатов занимает около 6.7 Гб. Процесс агрегирования всех отозванных и активных сертификатов занимает около 40 минут, а процесс генерации упакованной структуры на основе фильтра Блума требует ещё 20 минут.
В настоящее время в Mozilla обеспечено обновление БД CRLite четыре раза в день (не все обновления доставляются клиентам). Генерация delta-обновлений пока не реализована — применение bsdiff4, используемого для создания delta-обновлений релизов, не обеспечивает должную эффективность для CRLite и обновления получаются неоправданно большими. Для устранения этого недостатка планируется переработать формат структуры хранения для исключения лишнего перестроения и удаления слоёв.
CRLite пока работает в Firefox в пассивном режиме и используется параллельно с OCSP для накопления статистики о корректности работы. CRLite можно перевести в режим основной проверки, для этого в about:config нужно установить параметр security.pki.crlite_mode = 2.
Источник: opennet.ru