Når en privat nøgle kompromitteres, er standardanbefalingen at tilbagekalde certifikatet øjeblikkeligt. Det er korrekt råd — men den praktiske effekt af tilbagekaldelse er meget svagere end de fleste antager. I de fleste browsere vil et tilbagekaldt certifikat fortsætte med at blive accepteret i timer eller dage efter tilbagekaldelse. At forstå hvorfor forklarer meget om den reelle risikomodel ved certifikatkompromis.
Certifikattilbagekaldelse er den mekanisme der lader en Certificate Authority erklære et certifikat ugyldigt før dets naturlige udløbsdato. Det eksisterer fordi certifikater kan kompromitteres — en privat nøgle kan lække, en CA kan mis-udstede, eller en organisation kan sælges og have behov for at ugyldiggøre certifikater udstedt under det gamle navn. Tilbagekaldelse er hvordan PKI-økosystemet håndterer disse situationer. For en forklaring af certifikatkæden som tilbagekaldelse indgår i, se certifikatkæde forklaret.
Problemet er at tilbagekaldelseskontrol i praksis er fundamentalt brudt, og har været det i størstedelen af TLS's historie. Mekanismerne eksisterer, browsere implementerer dem inkonsistent, og de fail-open designbeslutninger truffet af tilgængelighedsårsager betyder at tilbagekaldte certifikater ofte fortsætter med at virke.
Hvordan tilbagekaldelse er tiltænkt at virke
Der er to primære mekanismer til certifikattilbagekaldelse: Certificate Revocation Lists (CRL'er) og Online Certificate Status Protocol (OCSP).
CRL'er er lister udgivet af CA'er der indeholder serienumrene på alle tilbagekaldte certifikater. En browser kan downloade CRL'en for et certifikats udstedende CA og kontrollere om certifikatets serienummer optræder på listen. CRL'er er begrebsmæssigt enkle men bliver uoverkommelige i skala — en CA der har udstedt millioner af certifikater kan have en CRL målt i megabytes, som browsere ikke praktisk kan downloade ved hver forbindelse.
OCSP (Online Certificate Status Protocol) blev designet til at løse CRL-skalerings problemet. I stedet for at downloade hele listen sender en browser en forespørgsel til CA'ens OCSP-responder med serienummeret på det specifikke certifikat den vil kontrollere, og modtager et signeret svar: gyldigt, tilbagekaldt eller ukendt. Dette er mere effektivt — én lille forespørgsel per certifikat — men indfører en afhængighed af at CA'ens OCSP-infrastruktur er tilgængelig.
Hvorfor OCSP-tilbagekaldelseskontrol fejler i praksis
Den kritiske designbeslutning der underminerer tilbagekaldelse er den fail-open adfærd de fleste browsere bruger til OCSP-tjek.
Hvis en browser ikke kan nå CA'ens OCSP-responder — fordi den er langsom, midlertidigt nede, eller blokeret af et netværksfilter — har browseren et valg: bloker forbindelsen (fail closed) eller tillad den (fail open). Næsten alle browsere valgte fail open, fordi alternativet er at netværksproblemer ved en CA ville forårsage udbredte forbindelsesfejl for brugere der ikke har noget at gøre med noget certifikatkompromis.
Det betyder at en angriber der opsnappes trafik med et tilbagekaldt certifikat blot kan blokere OCSP-forespørgslen. Browseren fejler med at få et tilbagekaldelsessvar, falder tilbage til sin fail-open adfærd og accepterer certifikatet. Tilbagekaldelse er omgået.
Ud over aktiv blokering er der strukturelle grunde til at tilbagekaldelsestjek er upålidelige:
- OCSP stapling er valgfrit og ofte ikke konfigureret. OCSP stapling har serveren for-hentende OCSP-svaret og inkluderer det i TLS-håndtrykket — eliminerer browserens afhængighed af CA'ens infrastruktur. Men stapling skal konfigureres på serveren, og mange servere har det ikke aktiveret.
- OCSP-svar caches. Selv når OCSP-tjek fungerer korrekt, caches svar i svarets gyldighedsperiode — typisk timer til dage. Et certifikat tilbagekaldt i dag kan stadig accepteres af browsere der cachede et "gyldigt" svar i går.
- Mobile browsere springer ofte OCSP over fuldstændigt. Batteri- og dataforbrug bekymringer fører til at nogle mobile browsere deaktiverer tilbagekaldelseskontrol. Et tilbagekaldt certifikat kan fuldt ud accepteres på mobil i hele dets originale levetid.
- Chrome opgav OCSP i 2012. Googles Chrome-browser udfører ikke live OCSP-tjek. I stedet bruger Chrome CRLSets — kuraterede, komprimerede lister over højprioritets tilbagekaldelser skubbet via browserens opdateringsmekanisme. Kun en lille brøkdel af tilbagekaldte certifikater optræder i CRLSets; det store flertal tjekkes aldrig af Chrome-brugere overhovedet.
Hvad tilbagekaldelse faktisk er nyttig til
Med disse begrænsninger er det rimeligt at spørge om tilbagekaldelse har nogen praktisk værdi. Det har den — men i et snævrere sæt omstændigheder end der almindeligvis antages:
Højtprofilerede kompromiser flagget af CA'er. Når en CA fastslår at et certifikat var alvorligt mis-udstedt — især for et højværdidomæne — kan de skubbe tilbagekaldelsen til CRLSets eller andre browseropdateringsmekanismer. Dette giver meningsfuld beskyttelse for en lille delmængde af tilbagekaldelser.
API-klienter og ikke-browser-kontekster. Mange API-klienter, mobile SDK'er og server-til-server kommunikationsbiblioteker implementerer strengere tilbagekaldelseskontrol end browsere. I disse kontekster kan tilbagekaldelse håndhæves mere pålideligt.
Langlivede certifikater. Jo længere et kompromitteret certifikat forbliver gyldigt, jo mere værdi har tilbagekaldelse. Under 47-dages certifikatlevetider krymper en angribers vindue til uger uanset tilbagekaldelse — den begrænsede certifikatlevetid selv bliver den primære afbødning.
Hvad der faktisk begrænser skaden fra et kompromitteret certifikat
Hvis tilbagekaldelse er upålideligt, er de effektive kontroller til at begrænse certifikatkompromis-skade:
- Korte certifikatlevetider. Et 47-dages certifikat kompromitteret på dag ét begrænser angribers anvendelse til maksimalt 47 dage. Et et-årig certifikat kompromitteret på dag ét giver angriberen 364 dage — uanset om det tilbagekaldes.
- Privat nøglesikkerhed. Den mest effektive kontrol er at sikre at private nøgler aldrig kompromitteres i første omgang — hardware security modules, streng adgangskontrol og krypteret lagring.
- Certificate Transparency-overvågning. CT-logs gør mis-udstedelse opdagbar hurtigt. Overvågning af CT-logs for uventede udstedelser til jeres domæner lader jer opdage om en CA har udstedt et certifikat til jeres domæne uden jeres vidende.
- OCSP stapling med Must-Staple. TLS Must-Staple-udvidelsen lader et certifikat erklære at det skal præsenteres med et stiftet OCSP-svar. Browsere der understøtter Must-Staple vil nægte forbindelser hvor stiftet mangler eller er forældet — eliminerer fail-open adfærden for disse certifikater.
Hvordan CertControl overvåger tilbagekaldelsestilstand
CertControl kontrollerer OCSP-tilstand for alle overvågede certifikater som del af hver scancyklus — markerer certifikater der er tilbagekaldt, har OCSP-respondenter der ikke kan nås, eller som ikke bruger OCSP stapling hvor det ville være gavnligt. Tilbagekaldelsestilstand vises i certifikat-detaljevisningen ved siden af udløb, kædesundhed og TLS-konfigurationsfindinger.
For certifikater hvor tilbagekaldelsesovervågning betyder mest — produktionscertifikater, certifikater der dækker høj-værditjenester, certifikater udstedt under managed CA-relationer — viser platformen OCSP-konfigurationsproblemer som findings med passende alvorlighedsvurderinger.
Ofte stillede spørgsmål
Hvad er forskellen på CRL og OCSP?
En CRL er en liste over alle tilbagekaldte serienumre udgivet af en CA, som bliver stor i skala. OCSP lader en klient forespørge tilstanden på ét specifikt certifikat og modtage et signeret gyldigt, tilbagekaldt eller ukendt svar, hvilket er mere effektivt men afhænger af at CA'ens responder kan nås.
Hvorfor virker tilbagekaldte certifikater ofte stadig?
De fleste browsere fejler open: hvis de ikke kan nå OCSP-responderen accepterer de certifikatet. Svar caches også i timer, mobile browsere springer ofte OCSP over, og Chrome bruger CRLSets der kun dækker en lille brøkdel af tilbagekaldelser.
Hvad er OCSP stapling og Must-Staple?
Med OCSP stapling henter serveren OCSP-svaret på forhånd og inkluderer det i TLS-håndtrykket, hvilket fjerner klientens afhængighed af CA'en. Must-Staple-udvidelsen tvinger browsere til at nægte forbindelser hvor et friskt staple mangler, hvilket eliminerer fail-open for disse certifikater.
Udfører Chrome OCSP-tjek?
Nej. Chrome opgav live OCSP-tjek i 2012 og bruger i stedet CRLSets — kuraterede, komprimerede lister over højprioritets tilbagekaldelser skubbet via browseropdateringer. Flertallet af tilbagekaldte certifikater tjekkes aldrig af Chrome-brugere.
Hvad begrænser faktisk skaden fra et kompromitteret certifikat?
Korte certifikatlevetider, stærk privat nøglesikkerhed, Certificate Transparency-overvågning for mis-udstedelse, og OCSP stapling med Must-Staple er mere effektive end at stole på tilbagekaldelse alene.