Mozilla Company tungkol sa pagsisimula ng pagsubok sa gabi-gabing build ng Firefox isang bagong mekanismo para sa pag-detect ng mga binawi na sertipiko - . Binibigyang-daan ka ng CRLite na ayusin ang epektibong pagsusuri sa pagbawi ng certificate laban sa isang database na naka-host sa system ng user. Ang pagpapatupad ng CRLite ng Mozilla sa ilalim ng libreng lisensya ng MPL 2.0. Ang code para sa pagbuo ng database at mga bahagi ng server ay nakasulat sa at umalis. Idinagdag ang mga bahagi ng kliyente sa Firefox para sa pagbabasa ng data mula sa database sa wikang Rust.
Pag-verify ng sertipiko gamit ang mga panlabas na serbisyo batay sa protocol na ginagamit pa rin (Online Certificate Status Protocol) ay nangangailangan ng garantisadong pag-access sa network, humahantong sa isang makabuluhang pagkaantala sa pagpoproseso ng kahilingan (350ms sa karaniwan) at may mga problema sa pagtiyak ng pagiging kumpidensyal (mga server ng OCSP na tumutugon sa mga kahilingan ay tumatanggap ng impormasyon tungkol sa mga partikular na certificate, na maaaring gamitin upang hatulan kung ano ang mga site na binubuksan ng user). Mayroon ding posibilidad ng lokal na pagsusuri laban sa mga listahan (Listahan ng Pagpapawalang-bisa ng Sertipiko), ngunit ang kawalan ng pamamaraang ito ay ang napakalaking sukat ng na-download na data - sa kasalukuyan ang database ng mga binawi na sertipiko ay sumasakop ng humigit-kumulang 300 MB at nagpapatuloy ang paglago nito.
Para harangan ang mga certificate na nakompromiso at binawi ng mga awtoridad sa certification, gumamit ang Firefox ng sentralisadong blacklist mula noong 2015 kasabay ng isang tawag sa serbisyo upang matukoy ang posibleng malisyosong aktibidad. OneCRL, tulad ng sa Chrome, nagsisilbing intermediate na link na pinagsasama-sama ang mga listahan ng CRL mula sa mga awtoridad sa certification at nagbibigay ng iisang sentralisadong serbisyo ng OCSP para sa pagsuri sa mga binawi na certificate, na ginagawang posible na hindi direktang magpadala ng mga kahilingan sa mga awtoridad sa certification. Sa kabila ng maraming trabaho upang pahusayin ang pagiging maaasahan ng online na serbisyo sa pag-verify ng sertipiko, ipinapakita ng data ng telemetry na higit sa 7% ng mga kahilingan ng OCSP ay nag-time out (ilang taon na ang nakalipas ang bilang na ito ay 15%).
Bilang default, kung imposibleng i-verify sa pamamagitan ng OCSP, itinuturing ng browser na wasto ang certificate. Maaaring hindi available ang serbisyo dahil sa mga problema sa network at mga paghihigpit sa mga panloob na network, o na-block ng mga umaatake - upang i-bypass ang tseke ng OCSP sa panahon ng pag-atake ng MITM, i-block lang ang access sa serbisyo ng tseke. Bahagyang upang maiwasan ang mga naturang pag-atake, isang pamamaraan ang ipinatupad , na nagpapahintulot sa iyo na ituring ang isang OCSP access error o OCSP unavailability bilang isang problema sa certificate, ngunit ang tampok na ito ay opsyonal at nangangailangan ng espesyal na pagpaparehistro ng certificate.
Binibigyang-daan ka ng CRLite na pagsamahin ang kumpletong impormasyon tungkol sa lahat ng binawi na mga sertipiko sa isang madaling na-update na istraktura, 1 MB lang ang laki, na ginagawang posible na mag-imbak ng kumpletong database ng CRL sa panig ng kliyente.
Magagawa ng browser na i-synchronize ang kopya nito ng data tungkol sa mga binawi na certificate araw-araw, at magiging available ang database na ito sa ilalim ng anumang kundisyon.
Pinagsasama ng CRLite ang impormasyon mula sa , isang pampublikong log ng lahat ng inisyu at binawi na mga sertipiko, at ang mga resulta ng pag-scan ng mga sertipiko sa Internet (iba't ibang mga listahan ng CRL ng mga awtoridad sa sertipikasyon ay kinokolekta at ang impormasyon tungkol sa lahat ng kilalang mga sertipiko ay pinagsama-sama). Ang data ay nakabalot gamit ang cascading , isang probabilistikong istraktura na nagbibigay-daan sa isang maling pagtuklas ng isang nawawalang elemento, ngunit hindi kasama ang pagtanggal ng isang umiiral na elemento (ibig sabihin, na may isang tiyak na posibilidad, ang isang maling positibo para sa isang tamang sertipiko ay posible, ngunit ang mga binawi na sertipiko ay ginagarantiyahan na matukoy).
Upang alisin ang mga maling positibo, ang CRLite ay nagpakilala ng mga karagdagang antas ng pagwawasto ng filter. Pagkatapos mabuo ang istraktura, hahanapin ang lahat ng source record at matukoy ang anumang maling positibo. Batay sa mga resulta ng tseke na ito, isang karagdagang istraktura ang nilikha, na inilalagay sa una at itinatama ang mga nagresultang maling positibo. Ang operasyon ay paulit-ulit hanggang ang mga maling positibo sa panahon ng control check ay ganap na maalis. Karaniwan, ang paggawa ng 7-10 layer ay sapat na upang ganap na masakop ang lahat ng data. Dahil ang estado ng database, dahil sa pana-panahong pag-synchronize, ay nahuhuli nang bahagya sa kasalukuyang estado ng CRL, ang pagsuri ng mga bagong sertipiko na ibinigay pagkatapos ng huling pag-update ng CRLite database ay isinasagawa gamit ang OCSP protocol, kasama ang paggamit ng (isang tugon ng OCSP na na-certify ng isang awtoridad sa sertipikasyon ay ipinadala ng server na nagsisilbi sa site kapag nakikipag-usap sa isang koneksyon sa TLS).
Gamit ang mga filter ng Bloom, ang bahagi ng Disyembre ng impormasyon mula sa WebPKI, na sumasaklaw sa 100 milyong aktibong mga sertipiko at 750 libong binawi na mga sertipiko, ay nai-pack sa isang istraktura na 1.3 MB ang laki. Ang proseso ng pagbuo ng istraktura ay medyo masinsinang mapagkukunan, ngunit ito ay isinasagawa sa Mozilla server at ang gumagamit ay binibigyan ng isang handa na pag-update. Halimbawa, sa binary form, ang source data na ginamit sa pagbuo ay nangangailangan ng humigit-kumulang 16 GB ng memory kapag naka-store sa Redis DBMS, at sa hexadecimal form, ang isang dump ng lahat ng certificate serial number ay tumatagal ng humigit-kumulang 6.7 GB. Ang proseso ng pagsasama-sama ng lahat ng binawi at aktibong certificate ay tumatagal ng humigit-kumulang 40 minuto, at ang proseso ng pagbuo ng isang naka-package na istraktura batay sa Bloom filter ay tumatagal ng isa pang 20 minuto.
Kasalukuyang tinitiyak ng Mozilla na ang CRLite database ay ina-update ng apat na beses sa isang araw (hindi lahat ng mga update ay inihahatid sa mga kliyente). Ang pagbuo ng mga update sa delta ay hindi pa naipapatupad - ang paggamit ng bsdiff4, na ginamit upang lumikha ng mga update sa delta para sa mga release, ay hindi nagbibigay ng sapat na kahusayan para sa CRLite at ang mga update ay hindi makatwirang malaki. Upang maalis ang disbentaha na ito, pinlano na muling ayusin ang format ng istraktura ng imbakan upang maalis ang hindi kinakailangang muling pagtatayo at pagtanggal ng mga layer.
Kasalukuyang gumagana ang CRLite sa Firefox sa passive mode at ginagamit kasabay ng OCSP upang makaipon ng mga istatistika tungkol sa tamang operasyon. Maaaring ilipat ang CRLite sa main scan mode, para magawa ito, kailangan mong itakda ang parameter na security.pki.crlite_mode = 2 sa about:config.
Pinagmulan: opennet.ru