OCSP versus un CRL: cum funcționează de fapt fiecare verificare de revocare

Una dintre aceste două verificări de revocare returnează un răspuns semnat despre un singur certificat, iar cealaltă returnează o listă semnată pe care o descarci integral. Ambele trebuie să spună unui verificator dacă o acreditare mai este de încredere, și ambele eșuează în moduri care nu se aseamănă deloc. Ordinea de mai jos urmează ceea ce întâlnește de fapt un operator în producție, începând cu octeții de pe fir și terminând cu o poartă care refuză o conexiune. Sărine un pas este felul în care o implementare ajunge cu o politică de revocare care există doar pe hârtie.

Pasul 1: Ce returnează fiecare verificare și cât timp rămâne utilizabilă

Un CRL este publicat ca un singur obiect semnat care acoperă fiecare certificat pe care un emitent l-a revocat, așa că un verificator îl ia o dată și îl refolosește până când nextUpdate al listei trece. Un răspuns OCSP este mai îngust: răspunde exact pentru un certificat și poartă thisUpdate, producedAt și de obicei și nextUpdate. Această diferență guvernează tot restul. Un CRL pus în cache devine învechit în tăcere, pentru că fișierul încă se parsează și semnătura lui încă se verifică, în timp ce un răspuns OCSP expirat este evident fără valoare în momentul în care îi citești marcajele de timp.

De aceea cache-ul este primul lucru de stabilit: ce componentă ține copia și la ce plafon se supune acea copie. Pe o poartă plafonul ar trebui să fie nextUpdate minus o marjă de siguranță, niciodată ceea ce sugerează din întâmplare un antet de cache HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate tipărește ambele date, și o listă al cărei nextUpdate este deja în trecut trebuie tratată ca lipsă și nu doar ca veche.

Pasul 2: Unde îndreaptă certificatul clientul

Certificatul frunză poartă de obicei două indicii: o extensie de punct de distribuție CRL și o intrare de acces la informațiile autorității pentru OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints tipărește prima, iar a doua se află sub secțiunea AIA a openssl x509 -in client.pem -noout -text. Oricare dintre extensii este un indicator, nu o obligație. Un client care nu implementează niciodată verificarea revocării se va conecta foarte bine la un certificat ale cărui extensii numesc un respondent mort de un an.

Punctele de distribuție numesc adesea un host intern care se rezolvă doar într-un singur segment de rețea, iar unii clienți mai vechi refuză pur și simplu adresele URL ldap. Testați accesibilitatea de pe hostul care termină tunelul, nu de pe propriul laptop, pentru că acesta este singurul punct de vedere a cărui eșec contează cu adevărat.

Pasul 3: Alegeți fail-closed sau fail-open înainte de cădere

Un respondent inaccesibil sau o listă expirată impun o decizie: refuzați conexiunea, sau o acceptați și înregistrați golul. Subcomanda verify din OpenSSL face explicită alegerea strictă, pentru că adăugarea lui -crl_check transformă un CRL indisponibil în unable to get certificate CRL și într-o verificare eșuată. Soft-fail în majoritatea stivelor nu este deloc un fanion, este absența verificării, și exact de aceea ajunge livrat din greșeală.

Pentru a vedea ce comportament are de fapt un client, scoateți respondentul și reconectați-vă. Dacă tunelul tot se ridică, găsiți linia de jurnal care a notat verificarea omisă și apoi întrebați-vă dacă cineva ar citi acea linie în timpul unui incident. Același furnizor poate diferi în funcție de protocol: un client IKEv2 și un client OpenVPN pe aceeași mașină citesc setări de configurare fără legătură.

Pasul 4: Dovediți că verificarea rulează acolo unde traficul este admis

Găsiți procesul care termină sau autorizează conexiunea și întrebați-l despre linia de configurare care activează verificarea revocării. O poartă care validează lanțul dar nu întreabă niciodată despre revocare aplică o politică diferită de cea din documentația voastră, iar nicio captură de ecran a unui lanț de certificate nu dovedește contrariul. OpenVPN scrie opțiunea ca crl-verify; strongSwan ține căutările CRL și OCSP sub configurația CA, unde se stabilesc crl_uris sau ocsp_uris. Dacă nu puteți indica niciuna dintre ele, presupuneți că verificarea lipsește.

Un răspuns OCSP contează doar când a fost semnat de CA emitentă, sau când a fost semnat de un respondent care are utilizarea extinsă a cheii OCSPSigning delegată de acea CA, așa că un răspuns de la un serviciu nelegat nu dovedește nimic. Dacă rulați singuri respondentul, monitorizați-l ca dependență dură, pentru că un singur serviciu mort devine deodată o cădere pentru fiecare client fail-closed.

Pasul 5: Revocați un certificat intenționat

Luați un certificat de test, revocați-l prin același canal pe care îl folosește producția și întrebați respondentul direct. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text ar trebui să raporteze Cert Status: revoked împreună cu un timp de revocare, iar un răspuns good înseamnă că revocarea voastră nu a ajuns la respondentul întrebat de clienții voștri. Apoi rulați openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem pentru a vedea aceeași decizie pe calea listei. Citiți șirul motivului în locul codului de ieșire, pentru că o respingere din cauza revocării și o eroare de lanț se termină amândouă cu eșec.

Pasul care contează cu adevărat este ultimul: reconectați-vă cu profilul vechi împotriva punctului real de aplicare și confirmați că refuzul vine din revocare. Apoi reconectați-vă cu un certificat nou și valid pentru a dovedi că nu ați stricat doar ascultătorul. Ștergerea profilului pe client nu dovedește nimic despre decizia serverului, și nici o execuție reușită a openssl verify pe o mașină care nu termină niciodată un tunel. RFC 6960 definește ce conține un răspuns OCSP conform, inclusiv valorile de stare pe care le citește acest test.