O Googlovih CRLSets je veliko kritik in nekatere od njih so utemeljene, vendar ni nobene zaščite za CRL in OCSP, saj trenutno delujeta.
Po napaki Heartbleed so se vsi končno naveličali kazati s prstom na OpenSSL, ker je bilo to preveč enostavno. Nova igra kazanja s prstom je med zagovorniki in nasprotniki Googlove sheme CRLSet za preverjanje preklica.
Prejšnji teden sem se postavil na Googlovo stran, vendar se drugi s tem ne strinjajo, vključno s Stevom Gibsonom, znanim razvijalcem. Gibsonov argument je v bistvu kritika CRLSets, ampak tudi brani obstoječi sistem.
AR + VR
- Ta očala XR v vrednosti 400 USD so mojemu MacBooku dala 120-palčni zaslon za delo
- Preizkusil sem Apple Vision Pro in je daleč pred tistim, kar sem pričakoval
- Najboljše slušalke VR za igranje iger, delo in drugo
- Spoznajte Applove slušalke AR/VR Vision Pro: cena, funkcije, datum izdaje in vse ostalo, kar morate vedeti
Googlov Adam Langley, ki je bil glasen na to temo, je obravnaval kritiko v svojem blogu. Langley je že leta v ospredju varnejšega spleta. Je eden tistih, ki je Gmailu in drugim pomembnim Googlovim storitvam omogočil popolnoma SSL, s čimer je prisilil druge prodajalce, da storijo enako. Imamo srečo, da Langley dela za pomembnega prodajalca, kot je Google.
Večina kritik CRLSetov se v bistvu nanaša na dejstvo, da ne vključujejo večine preklicanih potrdil. Google je poskušal pridobiti CA-je za sodelovanje pri razvoju CRLSets, vendar se zdi, da niso sodelovali. V svojem blogu Langley pojasnjuje zelo razumne zahteve, ki jih je postavil Google.
Pravzaprav Langley nadalje pokaže, da CRLSeti, kot trenutno delujejo, dolgoročno tako ali tako niso vzdržni. Preprosto postanejo preveliki, ker je preveč preklicanih certifikatov.
Toda alternative so očitno pokvarjene. Pojasnjuje na primer vlogo Microsoftove knjižnice, imenovane CAPI (kriptografska aplikacija). Programski vmesnik), ki obravnava preklic potrdila za programe Windows, kot je Internet Explorer in Chrome. Ko ima 50 ali več odgovorov OCSP za dano potrdilo CA, prenese CRL. CA to vedo in svoje CRL-je razdelijo na manjše datoteke, tako da jim ni treba ves čas streči velikih CRL-jev. To se norčuje iz trditvenih prednosti predpomnilnika CRL.
Mimogrede, Firefox ne uporablja CAPI, delno zato, ker pišejo lastne kripto knjižnice in delno zato, ker ne podpirajo niti CRL-jev. Za vse uporabljajo OCSP.
Po mojem zadnjem članku, ki je hvalil CRLSets, so me nagovorili varnostni svet CA, industrijska skupina CA. Navedli so nekaj enakih argumentov kot Gibson glede CRLSets, vendar se niso zelo trudili braniti trenutnega režima.
Vprašal sem jih, kaj bi lahko dolgoročno delovalo, in strinjali smo se, da je potrebna kombinacija novega standarda OCSP se mora spenjati in trda okvara bi bila učinkovita, zlasti v kombinaciji s kratkimi obdobji veljavnosti OCSP. Kaj vse to pomeni?
Spenjanje OCSP omogoča predstavitelju potrdila (npr. https://www.amazon.com) vključiti odgovor OCSP s potrdilom, ki ga predložijo strankam. To je veliko udobje in povečanje učinkovitosti za stranke (tiste, ki dejansko preverjajo preklic), vendar je le možnost.
OCSP Must Staple je pravilnik, ki pravi, da podajalec potrdila mora vključite speti odgovor ali stranko maj zavrniti povezavo.
Združite Must Staple s trdim neuspehom v primerih, ko odgovor ni zagotovljen ali kjer nakazuje preklic, in zagotovite dovolj dolgo veljavnost OCSP kratek (po možnosti ure) in imeli bi precej robusten sistem, ki bi zaščitil stranke pred preklicanimi potrdili (razen morda kmalu po preklicu).
Na žalost CA infrastruktura še zdaleč ni pripravljena na tak sistem. Zahtevala bi zelo visoko raven razpoložljivosti ali pa bi nenadoma veliko strank doživelo veliko hudih napak. Dejstvo, da so bili pred vsem tem zadovoljni z mehkimi napakami, kaže, kako resno jemljejo problem.
Pred kratkim, razprava o napaki Triple Handshake v TLS, sem poudaril, da lahko večji premiki standardov iz varnostnih razlogov uspejo le, če je vpleten velik, močan akter, ki lahko prisili igralce naprej. Glede na odziv na CRLSets se zdi (neverjetno), da Google ni dovolj velik in močan.
Toda Microsoft je.
Vsi programi, ki uporabljajo Windows Crypto API, preverjajo seznam zaupanja vrednih overiteljev potrdil, ki ga vzdržuje Microsoft za Windows. Izključitev s tega seznama bi bila smrt za CA. Microsoft te teže ne razmetava pogosto, vendar jo včasih. Na primer, s 1. januarjem 2016 CA-jem v programu ne bodo več dovolili izdajanja potrdil z uporabo SHA-1 kot algoritma zgoščevanja.
(Mimogrede bi pomislili, da bi bil ob vseh preklicah in ponovnih izdajah zdaj pravi čas, da začnete uporabljati SHA-2. Pogledal sem in nisem videl nobenega dokaza o tem.)
Če bi se Microsoft vključil v sistem za izboljšanje preklica in zanj postavil težo svojega programa za korensko potrdilo, lahko stavite, da bi to uspelo.