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

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 for øjeblikket lidt af et guldstrøg for certifikater på internettet, da flere og flere websteder implementerer HTTPS. Ud over de oplagte sikkerheds- og privatlivsfordele ved HTTPS er der en række grunde, som du måske vil overveje at flytte til en sikker forbindelse, som jeg skitserer i min artikel Tror du stadig ikke, at du har brug for HTTPS?. Almindeligvis kaldet "SSL-certifikater" eller "HTTPS-certifikater", opnår det bredere internettet dem i en sats, som vi aldrig tidligere har set i webens historie. Hver dag gennemgår jeg de øverste en million websteder på internettet og analyserer forskellige aspekter af deres sikkerhed og hver 6-måned, jeg udgiver en rapport. Du kan se rapporterne her, men det vigtigste resultat at fokusere på lige nu er vedtagelsen af ​​HTTPS.

Andel af de øverste en million sites på HTTPS.
Forstørre / Andel af de øverste en million sites på HTTPS.

Ikke alene fortsætter vi med at implementere HTTPS, også den hastighed, som vi gør det, er stigende. Dette er, hvad virkelige fremskridt ser ud. Processen med at opnå et certifikat er blevet mere og mere enkelt over tid og nu takket være det fantastiske Lad os kryptere, det er også gratis at få dem. Enkeltvis sender vi et certifikat underskrivningsanmodning (CSR) til certificeringsmyndigheden (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 hoste en udfordringskode et sted på en tilfældig sti på vores domæne. Når denne udfordring er opfyldt, udsteder den certifikatet, og vi kan derefter præsentere det for de besøgendes browsere og få det grønne hængelås og "HTTPS" i adresselinjen.

Processen med at opnå et certifikat.
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å det er alt godt. 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 - oftere end nogen af ​​os ønsker. Hackere kan gå efter et 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 alle, der forbinder vores websted - men det, der stopper andre, der bruger vores certifikat, er, at de ikke har vores private nøgle. Når en browser etablerer en sikker forbindelse til et websted, kontrollerer den, at serveren har den private nøgle til certifikatet, som den forsøger at bruge, og derfor kan ingen, men vi, bruge vores certifikat. Hvis en angriber får vores private nøgle, ændres det dog.

Server kompromis giver angriber vores private nøgle.
Forstørre / Server kompromis giver angriber vores private nøgle.

Nu hvor en angriber har fået 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, som er ikke dig, hvem kan bevise at de er du. Dette er et reelt problem, og før du tror "dette vil aldrig ske for mig", skal du huske heartbleed-bug. Denne lille bug i OpenSSL biblioteket tillod angribere at stjæle private nøgler, og du behøvede ikke engang at gøre noget forkert for at det skulle ske. Derudover er der utallige måder at private nøgler udsættes ved et uheld eller uagtsomhed. 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 den. 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 kunde skal acceptere det.

Anmodning om tilbagekaldelse.
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 skal bevise ejerskab af det pågældende certifikat, og når vi gør det, vil CA markere certifikatet som tilbagekaldt. Nu hvor certifikatet er tilbagekaldt, har vi brug for en måde at kommunikere denne tilbagekaldelse til enhver kunde, der måtte kræve oplysningerne. Lige efter tilbagekaldelsen ved de 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 ser browseren nu, at certifikatet er dårligt, og det bør ikke stole på. Browseren skal kaste en fejl og opgive forbindelsen. Hvis certifikatet ikke er på listen, er alt godt, og browseren kan fortsætte forbindelsen.

Downloadning af en CRL.
Forstørre / Downloadning af en CRL.

Problemet med en CRL er, at de indeholder mange tilbagekaldte certifikater fra den pågældende CA, der opretholder det. Uden at komme ind i for detaljer, brydes de ned ved hvert mellemliggende certifikat, som en CA har, og CA kan fragmentere listerne i mindre klumper. Uanset hvordan det er brudt, er det punkt, jeg vil lave, det samme: CRL er typisk ikke en ubetydelig størrelse. Det andet problem er, at hvis klienten ikke har en frisk 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 de rent faktisk er.

Det lyder ikke særlig godt, så hvad skal vi se 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!

Henter et OCSP-svar.
Forstørre / Henter et OCSP-svar.

Det er rigtigt, at OCSP tilbyder en betydelig fordel ved at hente en CRL, men den ydelsesfordel kommer med en pris (ikke hader du det, når det sker?). Omkostningerne er også meget betydelige: dit privatliv.

Når vi tænker på, hvad en OCSP-anmodning er - anmodningen om status for et meget enkelt 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 browserhistorik til en tredjepart, som du ikke engang vidste om, alt i navnet HTTPS-som udgjorde at give os mere sikkerhed og privatliv. Slags ironisk, huh?

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 og OCSP kontrol.
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?

CRL og OCSP servere nede.
CRL og OCSP servere nede.

Browseren har kun to valg her. Det kan nægte at acceptere certifikatet, fordi det ikke kan kontrollere tilbagekaldelsesstatusen, eller det kan tage en risiko og acceptere certifikatet uden at kende tilbagekaldelsesstatus. Begge disse muligheder kommer med deres fordele og ulemper. Hvis browseren nægter at acceptere certifikatet, så hver gang din CA har en dårlig dag, og deres infrastruktur går offline, bliver 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 dermed forbundne risici.

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

Kilde

Efterlad en kommentar

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.