Revocarea certificatelor – Provocări și cele mai bune practici
Revocarea unui certificat invalidează certificatul înainte de data de expirare programată. Există numeroase motive pentru revocarea unui certificat, inclusiv, dar fără a se limita la, compromiterea sau pierderea cheii private corespunzătoare, imposibilitatea cheii și multe altele. Deși revocarea este de obicei discutată în contextul certificatelor X.509, alte tipuri de certificate, cum ar fi secure shell (SSH) și o confidențialitate destul de bună (PGP) (da, ne referim la cheile publice PGP ca certificate) acceptă, de asemenea, revocarea. În ciuda faptului că conceptul de revocare are un suport larg, în paragrafele următoare vom arăta cum implementările sunt mai complicate, cu o mulțime de cazuri limită și un suport general slab.
Metode de revocare a certificatului
Cea mai obișnuită metodă de revocare a unui certificat este prin publicarea unei liste de certificate revocate pe care clienții le pot consuma. În lumea X.509, acest lucru se face printr-un Certificate Revocation List (CRL). Iîn acest caz, Certificate Authority (CA) publică CRL-ul care conține lista certificatelor, starea de revocare (adică, Revocat sau Hold), motivul revocării (adică, nespecificat, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn sau aACompromise) și momentul în care a avut loc revocarea (notă: conform RFC 5280 există o diferență între data revocării și data invalidității, dar Ballot CSC-12 din cadrul Forumului CA/Browser a simplificat acest lucru în 2021).
Deși CRL-urile funcționează în teorie, ele prezintă numeroase probleme în practică. Pentru ca CRL-ul să fie accesat, acesta trebuie să fie disponibil clientului în timp real și, prin urmare, trebuie să fie accesibil „online”. Deși acest lucru nu este de obicei o problemă atunci când navigați pe site-uri web de pe web-ul public, poate fi o problemă în rețelele private și în cazurile de utilizare care nu se bazează pe securitatea nivelului de transport (TLS) (de exemplu, validarea semnăturilor pe cod sau documente pe o mașină offline). În plus, dacă CA-ul este popular, este posibil să fi emis o mulțime de certificate, ceea ce poate duce la CRL-uri mari care consumă multă lățime de bandă, au un impact negativ asupra performanței și deschid posibilitățile de atacuri de tip denial of service (DoS). Pentru a combate acest lucru, CA-urile publică periodic noi CRL-uri, iar clienții stochează în cache rezultatele CRL-urilor, ceea ce duce la o altă problemă – învechirea CRL-urilor. Dacă un certificat a fost revocat, poate dura uneori până la 24 de ore înainte ca un client să vadă starea actualizată și, până atunci, poate fi prea târziu.
Pentru a depăși aceste probleme, Online Certificate Status Protocol (OCSP) a fost conceput. OCSP permite clienților să interogheze starea unui singur certificat în timp real, reducând astfel semnificativ dimensiunea datelor transferate și îmbunătățind performanța și atenuarea DoS. Cu toate acestea, deoarece clientul interoghează un anumit certificat în momentul în care este consumat, acesta transmite informații către CA despre serviciul pe care îl consumă clientul și, prin urmare, are probleme de confidențialitate. OCSP poate, de asemenea, să pună o povară considerabilă asupra CA-urilor, în special pentru certificatele care sunt consumate adesea de mai mulți clienți diferiți (de exemplu, pentru site-uri web populare). Protocoale precum OCSP with stapling au fost concepute pentru a depăși această problemă, dar nu au fost niciodată adoptate pe scară largă.
Deschidere nereușită vs. Închidere nereușită
Datorită dependenței de infrastructura CA pentru verificarea stării de revocare, clienții trebuie să decidă ce să facă dacă starea de revocare nu poate fi verificată. Ar trebui ca clientul să se deschidă în mod eșuat (adică să continue cu o operațiune precum accesarea site-ului web) sau ar trebui să se închidă în mod eșuat (adică să nu continue cu operațiunea, ceea ce ar putea însemna imposibilitatea accesării unui site web sau a instalării de software)? Eșecul închiderii leagă disponibilitatea sistemului de disponibilitatea infrastructurii CA. Eșecul deschiderii lasă ușa deschisă atacatorilor pentru a ataca infrastructura CA, astfel încât clienții să nu vadă că un certificat compromis a fost marcat ca revocat. Unele browsere aleg să deschidă în mod eșuat, în timp ce altele au optat să nu verifice nici măcar starea de revocare și se bazează în schimb pe certificate cu durată scurtă de viață.
Impactul unui certificat revocat
Dacă clientul poate detecta că certificatul este revocat, ce ar trebui să facă? Unele cazuri de utilizare sunt destul de evidente. De exemplu, într-un caz TLS în care un client interoghează starea certificatului în timp real, un certificat revocat înseamnă că endpoint-ul (de exemplu, serverul pe care încercați să îl accesați) nu ar trebui să fie de încredere și handshake-ul TLS ar trebui să se încheie. Dar ce se întâmplă cu alte… use cases unde a fost semnat ceva în trecut, înainte ca certificatul să fie revocat? De exemplu, software care a fost semnat în mod legitim code signed în trecut, înainte ca cheia sa privată să fie compromisă și certificatul să fie revocat? Ar trebui să treacă în continuare validarea? Ei bine, dacă clientul poate verifica că semnătura a fost produsă înainte de compromiterea cheii, atunci da, ar trebui să treacă validarea. Acesta este motivul pentru care marcarea temporală criptografică este atât de importantă – permite clientului să verifice în mod fiabil când a fost produs ceva, astfel încât să poată compara acest lucru cu datele de revocare și expirare. Notă: din punct de vedere tehnic cryptographic timestamping permite unui client să verifice dacă ceva a fost produs la sau înainte de o anumită dată, nu neapărat data la care au fost produse datele, dar această distincție depășește scopul acestei postări.
Cele mai bune practici
Având în vedere complexitățile revocării, sprijinul mixt pentru aceasta din partea clienților obișnuiți și ramificațiile utilizării necorespunzătoare, ce ar trebui să facă o întreprindere? Două dintre cele mai bune practici de urmat sunt:
1. Utilizați marcarea temporală criptografică
2. Folosește certificate cu durată scurtă de viață