OCSP kundrejt një CRL: si funksionon në të vërtetë çdo kontroll anulimi

Njëra nga këto dy kontrolle anulimi kthen një përgjigje të nënshkruar për një certifikatë të vetme, dhe tjetra kthen një listë të nënshkruar që e shkarkoni të plotë. Të dyja duhet t'i thonë një verifikuesi nëse një kredencial ende është i besueshëm, dhe të dyja dështojnë në mënyra që nuk ngjajnë aspak me njëra-tjetrën. Rendi më poshtë ndjek atë që një operator ndesh vërtet në prodhim, duke filluar nga bajtët në tel dhe duke përfunduar me një portë që refuzon një lidhje. Kapërcimi i një hapi është pikërisht mënyra se si një vendosje përfundon me një politikë anulimi që ekziston vetëm në letër.

Hapi 1: Çfarë kthen çdo kontroll dhe sa kohë mbetet i përdorshëm

Një CRL publikohet si një objekt i vetëm i nënshkruar që mbulon çdo certifikatë që një lëshues ka anuluar, prandaj një verifikues e merr një herë dhe e ripërdor derisa të kalojë nextUpdate i listës. Një përgjigje OCSP është më e ngushtë: përgjigjet saktësisht për një certifikatë dhe mban thisUpdate, producedAt dhe zakonisht edhe nextUpdate. Ky ndryshim drejton gjithçka tjetër. Një CRL e ruajtur në cache plaket në heshtje, sepse skedari ende analizohet dhe nënshkrimi i tij ende verifikohet, ndërsa një përgjigje OCSP e skaduar është padyshim e pavlefshme në momentin që lexoni vulat e kohës.

Prandaj caching është gjëja e parë që duhet përcaktuar: cili komponent mban kopjen dhe çfarë tavani ndjek ajo kopje. Në një portë tavani duhet të jetë nextUpdate minus një diferencë sigurie, kurrë jo ajo që sugjeron rastësisht një header cache HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate shtyp të dyja datat, dhe një listë, nextUpdate i së cilës është tashmë në të shkuarën, duhet trajtuar si mungesë dhe jo thjesht si e vjetër.

Hapi 2: Ku e drejton certifikata klientin

Certifikata gjethe zakonisht mban dy të dhëna: një zgjerim të pikës së shpërndarjes së CRL dhe një zë të aksesit të informacionit të autoritetit për OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints shtyp të parën, dhe e dyta ndodhet nën seksionin AIA të openssl x509 -in client.pem -noout -text. Secili prej zgjerimeve është një tregues, jo një detyrim. Një klient që nuk implementon kurrë kontrollin e anulimit do të lidhet shumë mirë me një certifikatë, zgjerimet e së cilës emërtojnë një përgjigjës që ka vdekur prej një viti.

Pikat e shpërndarjes shpesh emërtojnë një host të brendshëm që zgjidhet vetëm brenda një segmenti rrjeti, dhe disa klientë më të vjetër i refuzojnë URL-të ldap fare. Testoni arritshmërinë nga hosti që përfundon tunelin, jo nga laptopi juaj, sepse ky është këndvështrimi i vetëm, dështimi i të cilit vërtet ka rëndësi.

Hapi 3: Zgjidhni fail-closed ose fail-open përpara ndërprerjes

Një përgjigjës i paarritshëm ose një listë e skaduar detyrojnë një vendim: refuzo lidhjen, ose pranoje dhe regjistro boshllëkun. Nënkomanda verify e OpenSSL e bën zgjedhjen strikte eksplicite, sepse shtimi i -crl_check e kthen një CRL të padisponueshme në unable to get certificate CRL dhe në një verifikim të dështuar. Soft-fail në shumicën e stekëve nuk është aspak një flamur, është mungesa e kontrollit, dhe pikërisht prandaj dërgohet aksidentalisht.

Për të parë çfarë sjelljeje ka vërtet një klient, hiqni përgjigjësin dhe rilidhuni. Nëse tuneli përsëri ngrihet, gjeni rreshtin e regjistrit që regjistroi kontrollin e kapërcyer, dhe pastaj pyesni veten nëse dikush do ta lexonte atë rresht gjatë një incidenti. I njëjti furnizues mund të ndryshojë sipas protokollit: një klient IKEv2 dhe një klient OpenVPN në të njëjtin makinë lexojnë cilësime konfigurimi të palidhura.

Hapi 4: Provoni që kontrolli xhiron aty ku pranohet trafiku

Gjeni procesin që përfundon ose autorizon lidhjen, dhe pastaj pyesni atë për rreshtin e konfigurimit që aktivizon kontrollin e anulimit. Një portë që validon zinxhirin por nuk pyet kurrë për anulim zbaton një politikë të ndryshme nga ajo në dokumentacionin tuaj, dhe asnjë pamje ekrani e një zinxhiri certifikatash nuk provon të kundërtën. OpenVPN e shkruan opsionin si crl-verify; strongSwan i mban kërkimet CRL dhe OCSP nën konfigurimin e CA, ku caktohen crl_uris ose ocsp_uris. Nëse nuk mund të tregoni asnjërën, supozoni se kontrolli mungon.

Një përgjigje OCSP vlen vetëm kur e ka nënshkruar CA lëshuese, ose kur e ka nënshkruar një përgjigjës që ka përdorimin e zgjeruar të çelësit OCSPSigning të deleguar nga ajo CA, prandaj një përgjigje nga një shërbim i palidhur nuk provon asgjë. Nëse e drejtoni vetë përgjigjësin, monitorojeni si një varësi të fortë, sepse një shërbim i vdekur bëhet menjëherë një ndërprerje për çdo klient fail-closed.

Hapi 5: Anuloni qëllimisht një certifikatë

Merrni një certifikatë testuese, anulojeni përmes të njëjtit kanal që përdor prodhimi, dhe pyesni përgjigjësin drejtpërdrejt. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text duhet të raportojë Cert Status: revoked së bashku me një kohë anulimi, dhe një përgjigje good do të thotë që anulimi juaj nuk arriti te përgjigjësi që pyesin klientët tuaj. Pastaj ekzekutoni openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem për të parë të njëjtin vendim përmes rrugës së listës. Lexoni vargun e arsyes në vend të kodit të daljes, sepse një refuzim për anulim dhe një gabim zinxhiri përfundojnë të dy në dështim.

Hapi që ka vërtet rëndësi është i fundit: rilidhuni me profilin e vjetër kundrejt pikës reale të zbatimit dhe konfirmoni që refuzimi vjen nga anulimi. Pastaj rilidhuni me një certifikatë të re dhe të vlefshme për të provuar se nuk keni thyer vetëm dëgjuesin. Fshirja e profilit në klient nuk provon asgjë për vendimin e serverit, dhe as një ekzekutim i suksesshëm i openssl verify në një makinë që nuk e përfundon kurrë një tunel. RFC 6960 përcakton çfarë përmban një përgjigje OCSP konforme, duke përfshirë vlerat e statusit që lexon ky test.