Компания 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 услуга за проверка на оттеглени сертификати, която позволява да не се изпращат запитвания директно до удостоверяващите центрове. Въпреки значителните усилия за повишаване на надеждността на услугата за онлайн проверка на сертификати, данните от телеметрията показват, че над 7% от запитванията OCSP завършват с таймаут (преди няколко години този показател беше 15%).
По подразбиране, в случай на невъзможност за извършване на проверка чрез OCSP, браузерът счита сертификата за валиден. Услугата може да не е достъпна както поради мрежови проблеми и ограничения във вътрешните мрежи, така и да бъде блокирана от атакуващи — за да заобикалят проверката на OCSP по време на MITM атака, е достатъчно просто да блокират достъпа до услугата. Частично за предотвратяване на подобни атаки е реализирана техника , позволяваща трактуването на грешката при обращение по OCSP или недостъпността на OCSP като проблем с сертификата, но тази възможност е опционална и изисква специално оформление на сертификата.
CRLite позволява свиването на пълни данни за всички отзовани сертификати в лесно обновяема структура с размер само 1 MB, което дава възможност за съхранение на пълната база CRL на страната на клиента.
Браузерът ще може ежедневно да синхронизира своята копия на данните за отзованите сертификати, и тази БД ще бъде достъпна при всякакви условия.
CRLite обединява данни от , публичния лог на всички издадени и отзовани сертификати, и резултатите от сканирането на сертификати в интернет (събира се информация от различни CRL списъци на удостоверяващи центрове и се агрегира информация за всички известни сертификати). Данните се опаковат с използването на каскадни , вероятностна структура, допускаща фалшиви определения на липсващ елемент, но изключваща пропускането на съществуващ елемент (т.е. с определена вероятност е възможно фалшиво сработка на валиден сертификат, но отзованите сертификати ще бъдат гарантирано открити).
За да се изключат неверни сработвания в CRLite, са въведени допълнителни коригиращи нива на филтриране. След генерирането на структурата се извършва преглед на всички изходни записи и определяне на възникналите неверни сработвания. Въз основа на резултатите от тази проверка се създава допълнителна структура, която каскадно се налага на първата и коригира възникналите неверни сработвания. Операцията се повтаря, докато неверните сработвания при контролна проверка не бъдат напълно изключени. Обикновено за пълно покритие на всички данни е достатъчно създаването на 7-10 слоя. Поради периодичната синхронизация състоянието на базата данни изостава малко от актуалното състояние на CRL, така че проверката на нови сертификати, издадени след последното обновление на базата данни CRLite, се извършва с помощта на протокола OCSP, включително чрез техниката (сертификат с подпис, предоставен от удостоверяващия орган, се предава от сървъра на сайта по време на установяване на TLS връзката).
С помощта на Bloom филтри, декемврийският набор от данни от WebPKI, обхващащ 100 милиона активни сертификати и 750 хиляди отзовани сертификати, успя да бъде опакован в структура с размер 1.3 MB. Процесът на генериране на структурата е доста ресурсоемък, но се извършва на сървъра на Mozilla и на потребителя се предоставя вече готово обновление. Например, в бинарна форма, използваните при генерирането изходни данни изискват около 16 GB памет, когато се съхраняват в СУБД Redis, а в шестнадесетичен вид, дамп на всички серийни номера на сертификатите заема около 6.7 GB. Процесът на агрегиране на всички отзовани и активни сертификати отнема около 40 минути, а процесът на генериране на опакованата структура на базата на Bloom филтъра изисква още 20 минути.
В момента в Mozilla се осигурява обновление на базата данни CRLite четири пъти на ден (не всички обновления се доставят на клиентите). Генерирането на delta-обновления все още не е реализирано — използването на bsdiff4, приложен за създаване на delta-обновления на версиите, не осигурява нужната ефективност за CRLite и обновленията се оказват неоправдано големи. За да се отстрани този недостатък, се планира преосмисляне на формата на структурата на съхранение, за да се изключи излишното презаструктуриране и премахване на слоеве.
CRLite в момента работи в Firefox в пасивен режим и се използва паралелно с OCSP за натрупване на статистика относно коректността на работата. CRLite може да бъде преведен в режим на основна проверка; за целта в about:config трябва да се зададе параметърът security.pki.crlite_mode = 2.
Източник: opennet.ru
