Компанія 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