OCSP CRL baten aurka: nola egiten duen benetan errebokazio-egiaztapen bakoitzak lan

Bi errebokazio-egiaztapen hauetako batek ziurtagiri bakar bati buruzko sinatutako erantzuna itzultzen du, eta besteak oso-osorik deskargatzen duzun zerrenda sinatua. Biek egiaztatzaile bati esan behar diote kredentziala oraindik fidagarria den ala ez, eta biek huts egiten dute elkarren antzik batere ez duten moduetan. Beheko ordenak operadoreak produkzioan benetan aurkitzen duena jarraitzen du, kablean dauden byteetatik hasi eta konexioa ukatzen duen ate bateraino. Urrats bat saltatzea da hedapen bat paperean soilik dagoen errebokazio-politika batekin amaitzen den modua.

Urratsa 1: Zer itzultzen duen egiaztapen bakoitzak eta zenbat denboraz jarraitzen duen erabilgarri

CRL sinatutako objektu bakar gisa argitaratzen da, igorleak errebokatu duen ziurtagiri bakoitza estaltzen duena, beraz egiaztatzaileak behin eskuratzen du eta berrerabili egiten du zerrendaren nextUpdate pasa arte. OCSP erantzuna estuagoa da: ziurtagiri bakar baterako erantzuten du eta thisUpdate, producedAt eta normalean nextUpdate ere eramaten ditu. Alde horrek gainerako guztia gidatzen du. Cachean gordetako CRL isilean zahartzen da, fitxategia oraindik analizatzen delako eta haren sinadura oraindik egiaztatzen delako, eta OCSP erantzun iraungia, berriz, argi eta garbi baliogabea da haren denbora-markak irakurtzen dituzun unetik.

Beraz, cachea da lehenengo finkatu beharrekoa: zein osagak gordetzen duen kopia eta kopia horrek zein sabai betetzen duen. Ate batean sabaiak nextUpdate ken segurtasun-marjina bat izan behar du, inoiz ez HTTP cache goiburu batek kasualitatez proposatzen duena. openssl crl -in issuer.crl -noout -lastupdate -nextupdate aginduak bi datak inprimatzen ditu, eta nextUpdate jadanik iraganean duen zerrenda bat falta den zerbait bezala tratatu behar da, eta ez soilik zahar gisa.

Urratsa 2: Nora bideratzen du ziurtagiriak bezeroa

Hostoko ziurtagiriak normalean bi arrasto eramaten ditu: CRL banaketa-puntuaren luzapen bat eta OCSPrako autoritate-informazioko sarbide-sarrera bat. Lehena openssl x509 -in client.pem -noout -ext crlDistributionPoints aginduak inprimatzen du, eta bigarrena openssl x509 -in client.pem -noout -text aginduaren AIA atalean dago. Luzapenetako edozein erakusle bat da, ez betebehar bat. Inoiz errebokazio-egiaztapena inplementatzen ez duen bezero bat ondo konektatuko da urtebetez hilda dagoen erantzule bat izendatzen duten luzapenak dituen ziurtagiri batekin.

Banaketa-puntuek sarritan sare-segmentu bakar baten barruan soilik ebazten den barne-host bat izendatzen dute, eta bezero zahar batzuek ldap URLak erabat ukatzen dituzte. Irisgarritasuna tunela amaitzen duen hostetik probatu, eta ez zure ordenagailu eramangarritik, hori baita hutsegiteak benetan axola duen ikuspegi bakarra.

Urratsa 3: Aukeratu fail-closed edo fail-open etenaren aurretik

Erantzule iristezin batek edo iraungitako zerrenda batek erabakia behartzen du: ukatu konexioa, edo onartu eta hutsunea erregistratu. OpenSSLren verify azpikomandoak aukera zorrotza esplizitu egiten du, -crl_check gehitzeak erabilgarri ez dagoen CRL bat unable to get certificate CRL eta egiaztapen huts bat bihurtzen baitu. Soft-fail gehienetan ez da inolako bandera, egiaztapenaren absentzia baizik, eta horregatik iristen da istripuz.

Bezero batek benetan zer portaera duen ikusteko, kendu erantzulea eta konektatu berriro. Tunela oraindik altxatzen bada, bilatu saltatutako egiaztapena erregistratu zuen log lerroa, eta galdetu ea norbaitek lerro hori irakurriko lukeen gertaera batean. Hornitzaile berak protokoloaren arabera desberdin joka dezake: makina berean IKEv2 bezero batek eta OpenVPN bezero batek konfigurazio-konmutagailu desberdinak irakurtzen dituzte.

Urratsa 4: Frogatu egiaztapena trafikoa onartzen den tokian exekutatzen dela

Bilatu konexioa amaitzen edo baimena ematen duen prozesua, eta galdetu hari errebokazio-egiaztapena gaitzen duen konfigurazio-lerroa. Katea balioztatzen duen baina inoiz errebokazioaz galdetzen ez duen ate batek zure dokumentazioan dagoenaren desberdina den politika aplikatzen du, eta ziurtagiri-kate baten pantaila-argazkiak ez du kontrakoa frogatzen. OpenVPNek aukera crl-verify bezala idazten du; strongSwanek CRL eta OCSP bilaketak CA konfigurazioaren pean mantentzen ditu, non crl_uris edo ocsp_uris ezartzen diren. Bi horietako bat ere seinalatu ezin baduzu, pentsa ezazu egiaztapena falta dela.

OCSP erantzun batek balio du soilik jaulkitzaile CAk sinatu duenean, edo CA horrek eskuordeturiko OCSPSigning gako-erabilera hedatuaren jabe den erantzule batek sinatu duenean, beraz erlazionatuta ez dagoen zerbitzu baten erantzunak ez du ezer frogatzen. Erantzulea zuk zeuk exekutatzen baduzu, monitorizatu menpekotasun gogor gisa, zerbitzu hildako batek fail-closed bezero guztientzako eten bat bihurtzen baita aldi berean.

Urratsa 5: Errebokatu ziurtagiri bat nahita

Hartu proba-ziurtagiri bat, errebokatu produkzioak erabiltzen duen kanal beretik, eta galdetu erantzuleri zuzenean. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text tresnak Cert Status: revoked jakinarazi beharko luke errebokazio-ordu batekin batera, eta good erantzun batek esan nahi du zure errebokazioak ez duela zure bezeroek galdetzen dioten erantzulera iritsi. Ondoren exekutatu openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem erabaki bera zerrendaren bideetik ikusteko. Irakurri arrazoi-katea irteera-kodea baino, errebokazio-ukapen batek eta kate-errore batek biak huts egiten baitute.

Benetan axola duen urratsa azkena da: konektatu berriro profil zaharrarekin benetako betearazpen-puntuaren aurka eta egiaztatu ukoa errebokaziotik datorrela. Ondoren konektatu berriro ziurtagiri berri eta baliozko batekin, entzulea soilik hautsi ez duzula frogatzeko. Bezeroaren profila ezabatzeak ez du ezer frogatzen zerbitzariaren erabakiari buruz, eta ezta tunel bat inoiz amaitzen ez duen makinan openssl verify ondo exekutatzeak ere. RFC 6960 estekan zehazten da OCSP erantzun adostu baten edukia, proba honek irakurtzen dituen egoera-balioak barne.