HTTPS-certifikat tilbagekaldelse er brudt, og det er tid til nogle nye værktøjer

grabbyhands-800x531-1-8307536
Forstørre / Damn computer hackere, forsøger altid at stjæle alle mine ting.

Denne artikel blev oprindeligt offentliggjort den Scott Helmes blog og genoptrykes her med hans tilladelse.

Vi har et lille problem på internettet lige nu, og jeg kan kun se det blive en større bekymring i takt med at tiden går: flere og flere websteder får certifikater, vigtige dokumenter, der er nødvendige for at installere HTTPS, men vi har ingen måde at beskytte os selv på ting går galt.

Certifikater

Vi ser i øjeblikket lidt af et guldrusel for certifikater på Internettet, da flere og flere websteder implementerer HTTPS. Ud over de åbenlyse sikkerheds- og privatlivsfordele ved HTTPS er der ganske mange grunde til, at du måske vil overveje at flytte til en sikker forbindelse, som jeg skitserer i min artikel. Tror du stadig, at du ikke har brug for HTTPS?. Almindeligvis omtalt som "SSL-certifikater" eller "HTTPS-certifikater", får det bredere internet dem til en sats, vi aldrig har set før i webhistorikken. Hver dag gennemsøger jeg den øverste million steder på Internettet og analyserer forskellige aspekter af deres sikkerhed, og hver 6 måned offentliggør jeg en rapport. Du kan se rapporterne her, men det vigtigste resultat at fokusere på lige nu er vedtagelsen af ​​HTTPS.

top-1-million-på-https-procent-640x417-7424842
Forstørre / Andel af de øverste en million sites på HTTPS.

Vi fortsætter ikke kun med at implementere HTTPS, men den hastighed, hvormed vi gør det, stiger også. Sådan ser de virkelige fremskridt ud. Processen med at få et certifikat er blevet mere og mere enkel med tiden og nu takket være det fantastiske Lad os kryptere, det er også gratis at få dem. Kort sagt sender vi en anmodning om certifikatsignering (CSR) til Certificate Authority (CA), og CA vil udfordre os til at bevise vores ejerskab af domænet. Dette gøres normalt ved at indstille en DNS TXT-post eller være vært for en udfordringskode et eller andet sted på en tilfældig sti på vores domæne. Når denne udfordring er opfyldt CA, udsteder den certifikatet, og vi kan derefter præsentere det for besøgende 'browsere og få det grønne hængelås og “HTTPS” i adresselinjen.

opnår-et-certifikat-640x343-2146412
Forstørre / Processen med at opnå et certifikat.

Jeg har et par tutorials til at hjælpe dig med denne proces, herunder hvordan kom igang, hvordan man opsætter smart fornyelse, og hvordan man bruger det to certifikater. Så alt dette er fantastisk. Hvad er problemet?

Problemet er, når tingene ikke går efter planen, og du har en dårlig dag.

”Vi er blevet hacket!”

Ingen vil nogensinde høre disse ord, men den triste virkelighed er, at vi gør det - oftere end nogen af ​​os ønsker. Hackere kan gå efter et hvilket som helst antal ting, når de får adgang til vores servere, og ofte er en af ​​de ting, de kan få adgang til, vores private nøgle. De certifikater, vi bruger til HTTPS, er offentlige dokumenter - vi sender dem til enhver, der opretter forbindelse til vores websted - men det, der stopper andre mennesker ved at bruge vores certifikat, er, at de ikke har vores private nøgle. Når en browser opretter en sikker forbindelse til et websted, kontrollerer den, at serveren har den private nøgle til det certifikat, den prøver at bruge, og det er grunden til, at ingen andre end os kan bruge vores certifikat. Hvis en angriber imidlertid får vores private nøgle, ændres tingene.

server-kompromis-640x396-5503639
Forstørre / Server kompromis giver angriber vores private nøgle.

Nu hvor en angriber har formået at få vores private nøgle, kan de bruge vores certifikat til at bevise, at de er os. Lad os sige det igen: Hvis din nøgle er stjålet, betyder det, at der er nogen på Internettet, der er ikke dig, hvem kan bevise at de er du. Dette er et reelt problem, og før du tænker, "dette vil aldrig ske med mig," skal du huske heartbleed-bug. Denne lille fejl i OpenSSL-biblioteket gjorde det muligt for angribere at stjæle private nøgler, og du behøvede ikke engang at gøre noget galt for at det kunne ske. På toppen af ​​dette er der utallige måder, hvor private nøgler udsættes for ved uheld eller forsømmelse. Den enkle sandhed er, at vi kan mister vores private nøgler, og når dette sker, har vi brug for en måde at stoppe en angriber fra at bruge vores certifikat. Vi er nødt til tilbagekalde certifikatet.

Tilbagekaldelse

I et kompromisscenario tilbagekalder vi vores certifikat, så en angriber ikke kan misbruge det. Når et certifikat er markeret som "tilbagekaldt", vil webbrowsere vide, at de ikke har tillid til det, selvom certifikatet er gyldigt. Ejeren har anmodet om tilbagekaldelse, og ingen klient skal acceptere den.

tilbagekaldelse-640x312-6265739
Forstørre / Anmodning om tilbagekaldelse.

Når vi ved, at vi har haft et kompromis, kontakter vi CA og beder om, at de tilbagekalder vores certifikat. Vi er nødt til at bevise ejerskab af det pågældende certifikat, og når vi gør det, markerer CA certifikatet som ophævet. Nu, hvor certifikatet er ophævet, har vi brug for en måde at kommunikere denne tilbagekaldelse til enhver klient, der muligvis kræver oplysningerne. Lige efter tilbagekaldelsen ved besøgende 'browsere ikke om det - og det er selvfølgelig et problem. Der er to mekanismer, som vi kan bruge til at gøre disse oplysninger tilgængelige: en CRL (Certificate Revocation List) eller Online Certificate Status Protocol (OCSP).

Certificate Revocation Lists

En CRL er et virkelig simpelt koncept og er ret bogstaveligt bare en liste over alle certifikater, som en CA har markeret som tilbagekaldt. En klient kan kontakte CRL-serveren og hente en kopi af listen. Bevæbnet med en kopi af listen kan browseren tjekke for at se, om certifikatet det er blevet leveret, er på listen. Hvis certifikatet is på listen ved browseren nu, at certifikatet er dårligt, og det skal ikke være tillid. Browseren skal kaste en fejl og opgive forbindelsen. Hvis certifikatet ikke er på listen, er alt i orden, og browseren kan fortsætte forbindelsen.

download-crl-640x368-5938840
Forstørre / Downloadning af en CRL.

Problemet med en CRL er, at de indeholder en masse tilbagekaldte certifikater fra den særlige CA, der opretholder den. Uden at få for mange detaljer opdeles de efter hvert mellemliggende certifikat, som en CA har, og CA kan fragmentere listerne i mindre bunker. Uanset hvordan det er brudt op, forbliver det punkt, jeg vil gøre, det samme: CRL er typisk ikke en ubetydelig størrelse. Det andet problem er, at hvis klienten ikke har en ny kopi af CRL, skal den hente en under den oprindelige forbindelse til dit websted — hvilket kan få dit websted til at se meget langsommere ud, end det faktisk er.

Dette lyder ikke særlig godt - så hvad med at tage et kig på OCSP?

Online-certifikatstatusprotokol

OCSP giver en meget pænere løsning på problemet og har en betydelig fordel i forhold til CRL-tilgangen. Med OCSP spørger vi CA for status for et enkelt, specifikt certifikat. Det betyder, at alt CA skal gøre, er at reagere med et godt / tilbagekaldt svar, hvilket er betydeligt mindre end en CRL. Gode ​​sager!

ocsp-respons-fetch-640x370-4108546
Forstørre / Henter et OCSP-svar.

Det er sandt, at OCSP tilbyder en betydelig ydelsesfordel frem for at hente en CRL, men den ydelsesfordel kommer med en omkostning (hader du ikke det, når det sker?). Omkostningerne er også ret betydelige: dit privatliv.

Når vi tænker over, hvad en OCSP-anmodning er - anmodningen om status for et meget specifikt, enkelt certifikat - kan du begynde at indse, at du lækker nogle oplysninger. Når du sender en OCSP-anmodning, spørger du grundlæggende CA dette:

Er certifikatet for pornhub.com gyldigt?

Så ikke ligefrem et ideelt scenario. Du annoncerer nu din browseshistorik til en tredjepart, som du ikke engang vidste om, alt sammen med HTTPS-navn - som sigter mod at give os mere sikkerhed og privatliv. Slags ironisk, ikke?

Hårdt svigt

Men vent: der er noget andet. Jeg talte om CRL- og OCSP-svarene ovenfor, de to mekanismer, som en browser kan bruge til at kontrollere, om et certifikat er tilbagekaldt. De ser sådan ud.

crl-and-ocsp-checks-1695883
CRL og OCSP kontrol.

Efter modtagelsen af ​​certifikatet vil browseren nå ud til en af ​​disse tjenester og udføre den nødvendige forespørgsel for endelig at fastslå certifikatets status. Men hvad nu hvis din CA har en dårlig dag, og infrastrukturen er offline? Hvad hvis det ser ud som dette?

no-crl-or-ocsp-available-5668857
CRL og OCSP servere nede.

Browseren har kun to valg her. Det kan nægte at acceptere certifikatet, fordi det ikke kan kontrollere tilbagekaldelsesstatus, eller det kan tage en risiko og acceptere certifikatet uden at kende status for tilbagekaldelse. Begge disse indstillinger har deres fordele og ulemper. Hvis browseren nægter at acceptere certifikatet, så hver gang din CA har en dårlig dag, og deres infrastruktur slukker offline, går dine websteder også offline. Hvis browseren fortsætter og accepterer certifikatet, risikerer den at bruge et certifikat, der kunne have været stjålet, og udsætter brugeren for de tilknyttede risici deraf.

Det er et hårdt opkald - men lige nu i dag sker der faktisk ingen af ​​disse.

Kilde