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