Mozilla Şirketi
Применяемая до сих пор поверка сертификатов с привлечением внешних служб на базе протокола
Для блокирования скомпрометированных и отозванных удостоверяющими центрами сертификатов в Firefox с 2015 года используется централизованный чёрный список
По умолчанию, в случае невозможности осуществить проверку через OCSP, браузер считает сертификат корректным. Сервис может быть недоступен как из-за сетевых проблем и ограничений внутренних сетях, так и блокирован атакующими — для обхода проверки OCSP в ходе MITM-атаки достаточно просто заблокировать доступ к сервису проверки. Частично для предотвращения подобных атак реализована техника
CRLite позволяет свести полные сведения обо всех отозванных сертификатах в легко обновляемую структуру, размером всего 1 MB, что даёт возможность хранить полную базу CRL на стороне клиента.
Браузер сможет ежедневно синхронизировать свою копию данных об отозванных сертификатах, и эта БД будет доступна при любых условиях.
CRLite объединяет сведения из
Для исключения ложных срабатываний в 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.
Kaynak: opennet.ru