Mozilla внедряет CRLite для проверки проблемных TLS-сертификатов
Компания Mozilla объявила о начале тестирования в ночных сборках Firefox нового механизма определения отозванных сертификатов — CRLite. CRLite позволяет организовать эффективную проверку отзыва сертификатов по базе данных, размещаемой на системе пользователя. Развиваемая в Mozilla реализация CRLite опубликована под свободной лицензией MPL 2.0. Код для генерации БД и серверные компоненты написаны на Python и Go. Добавленные в Firefox клиентские части для чтения данных из БД подготовлены на языке Rust.
Применяемая до сих пор поверка сертификатов с привлечением внешних служб на базе протокола OCSP (Online Certificate Status Protocol) требует наличия гарантированного сетевого доступа и приводит к возникновению ощутимой задержки на обработку запроса (в среднем 350 мс). Организация локальной проверки по спискам CRL (Certificate Revocation List) затруднена большим размером данных — в настоящее время БД отозванных сертификатов занимает около 300 МБ и её рост продолжается.
Для блокирования скомпрометированных и отозванных удостоверяющими центрами сертификатов в Firefox с 2015 года используется централизованный чёрный список OneCRL в сочетании с обращением к сервису Google Safe Browsing для определения возможной вредоносной активности. Несмотря на большую работу по повышению надёжности сервиса online-проверки сертификатов, данные телеметрии показывают, что более 7% запросов OCSP завершается таймаутом (несколько лет назад этот показатель составлял 15%).
Сервис может быть недоступен как из-за сетевых проблем и ограничений внутренних сетях, так и блокирован атакующими — для обхода проверки OCSP в ходе MITM-атаки достаточно просто заблокировать доступ к сервису проверки. Частично для предотвращения подобных атак реализована техника Must-Staple, позволяющая трактовать ошибку обращения по OCSP как проблему с сертификатом, но данная возможность опциональна и требует специального оформления сертификата.
CRLite позволяет свести полные сведения о всех отозванных сертификатах в легко обновляемую структуру, размером всего 1 MB, что даёт возможность хранить полную базу CRL на стороне клиента. Браузер сможет ежедневно синхронизировать свою копию данных об отозванных сертификатах и эта БД будет доступна при любых условиях.
CRLite объединяет сведения из Certificate Transparency, публичного лога всех выданных и отозванных сертификатов, и результатов сканирования сертификатов в интернете (собираются различные CRL-списки удостоверяющих центров и агрегируется информация о всех известных сертификатах). Данные упаковываются с использованием каскадных фильтров Блума, вероятностной структуры, допускающей ложное определение отсутствующего элемента, но исключающей пропуск существующего элемента (т.е. с определённой вероятностью возможно ложное срабатывание на корректный сертификат, но отозванные сертификаты гарантированно будут выявлены).
Для исключения ложных срабатываний в CRLite введены дополнительные корректирующие уровни фильтра. После генерации структуры осуществляется перебор всех исходных записей и определение возникших ложных срабатываний. По результатам данной проверки создаётся дополнительная структура, которая каскадно накладывается на первую и корректирует возникшие ложные срабатывания. Операция повторяется до тех пор, пока ложные срабатывания при контрольной проверке не будут полностью исключены. Обычно для полного покрытия всех данных достаточно создания 7–10 слоёв. Так как состояние БД из-за периодической синхронизации немного отстаёт от актуального состояния CRL, проверка новых сертификатов, выписанных после последнего обновления БД CRLite, осуществляется при помощи протокола OCSP.
При помощи фильтров Блума декабрьский срез сведений из 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.
Источник: http://www.opennet.ru/opennews/art.shtml? num=52175
Применяемая до сих пор поверка сертификатов с привлечением внешних служб на базе протокола OCSP (Online Certificate Status Protocol) требует наличия гарантированного сетевого доступа и приводит к возникновению ощутимой задержки на обработку запроса (в среднем 350 мс). Организация локальной проверки по спискам CRL (Certificate Revocation List) затруднена большим размером данных — в настоящее время БД отозванных сертификатов занимает около 300 МБ и её рост продолжается.
Для блокирования скомпрометированных и отозванных удостоверяющими центрами сертификатов в Firefox с 2015 года используется централизованный чёрный список OneCRL в сочетании с обращением к сервису Google Safe Browsing для определения возможной вредоносной активности. Несмотря на большую работу по повышению надёжности сервиса online-проверки сертификатов, данные телеметрии показывают, что более 7% запросов OCSP завершается таймаутом (несколько лет назад этот показатель составлял 15%).
Сервис может быть недоступен как из-за сетевых проблем и ограничений внутренних сетях, так и блокирован атакующими — для обхода проверки OCSP в ходе MITM-атаки достаточно просто заблокировать доступ к сервису проверки. Частично для предотвращения подобных атак реализована техника Must-Staple, позволяющая трактовать ошибку обращения по OCSP как проблему с сертификатом, но данная возможность опциональна и требует специального оформления сертификата.
CRLite позволяет свести полные сведения о всех отозванных сертификатах в легко обновляемую структуру, размером всего 1 MB, что даёт возможность хранить полную базу CRL на стороне клиента. Браузер сможет ежедневно синхронизировать свою копию данных об отозванных сертификатах и эта БД будет доступна при любых условиях.
CRLite объединяет сведения из Certificate Transparency, публичного лога всех выданных и отозванных сертификатов, и результатов сканирования сертификатов в интернете (собираются различные CRL-списки удостоверяющих центров и агрегируется информация о всех известных сертификатах). Данные упаковываются с использованием каскадных фильтров Блума, вероятностной структуры, допускающей ложное определение отсутствующего элемента, но исключающей пропуск существующего элемента (т.е. с определённой вероятностью возможно ложное срабатывание на корректный сертификат, но отозванные сертификаты гарантированно будут выявлены).
Для исключения ложных срабатываний в CRLite введены дополнительные корректирующие уровни фильтра. После генерации структуры осуществляется перебор всех исходных записей и определение возникших ложных срабатываний. По результатам данной проверки создаётся дополнительная структура, которая каскадно накладывается на первую и корректирует возникшие ложные срабатывания. Операция повторяется до тех пор, пока ложные срабатывания при контрольной проверке не будут полностью исключены. Обычно для полного покрытия всех данных достаточно создания 7–10 слоёв. Так как состояние БД из-за периодической синхронизации немного отстаёт от актуального состояния CRL, проверка новых сертификатов, выписанных после последнего обновления БД CRLite, осуществляется при помощи протокола OCSP.
При помощи фильтров Блума декабрьский срез сведений из 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.
Источник: http://www.opennet.ru/opennews/art.shtml? num=52175
Ещё новости по теме:
18:20