Кампанія 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 хвілін, а працэс генерацыі запакаваная структуры на аснове фільтра Блюма патрабуе яшчэ XNUMX хвілін.
У цяперашні час у Mozilla забяспечана абнаўленне БД CRLite чатыры разы на дзень (не ўсе абнаўленні дастаўляюцца кліентам). Генерацыя delta-абнаўленняў пакуль не рэалізаваная - ужыванне bsdiff4, выкарыстоўванага для стварэння delta-абнаўленняў рэлізаў, не забяспечвае належную эфектыўнасць для CRLite і абнаўленні атрымліваюцца неапраўдана вялікімі. Для ўхілення гэтага недахопу плануецца перапрацаваць фармат структуры захоўвання для выключэння лішняга перастраення і выдаленні пластоў.
CRLite пакуль працуе ў Firefox у пасіўным рэжыме і выкарыстоўваецца раўналежна з OCSP для назапашвання статыстыкі аб карэктнасці працы. CRLite можна перавесці ў рэжым асноўнай праверкі, для гэтага ў about:config трэба ўсталяваць параметр security.pki.crlite_mode=2.
Крыніца: opennet.ru