Optimalisering av sidebelastning: OCSP-stifting

Introduksjon

Når en bruker besøker HTTPS-nettstedet, må den svare når det fungerer offentlig nøkkel, og et gyldig SSL-sertifikat som knytter nøkkelen til identiteten din, enten som person, firma eller organisasjon. Sertifikater utstedes alltid med en forhåndsdefinert utløpsdato som er inkludert i selve det signerte sertifikatet, og nettlesere sjekker alltid utløpsdatoen og vil avvise ethvert utløpt sertifikat.

I visse tilfeller må imidlertid et sertifikat merkes som ugyldig (og tilliten til disse sertifikatene må være opphevet) før du den utløper. Vanlige eksempler inkluderer en servereier som har bevis (eller ganske enkelt mistenker) om at den private nøkkelen deres ble kompromittert (dvs. at den gikk tapt, ble stjålet eller ødelagt), siden en tredjepart som innehar denne private nøkkelen i det vesentlige kan omgå alle nettverkets sikkerhetskontroller i nettleseren.

Som en konsekvens krevde nettleserleverandører offentlig klarert sertifikatmyndigheter (instanser) for å implementere minst en metode for både å tilbakekalle problematiske sertifikater og for å varsle nettlesere om å avvise disse tilbakekalte sertifikatene.

For eksempler på nettlesefeilmeldinger som følge av tilbakekalte sertifikater, se Denne guiden. Du kan sjekke sertifikatets tilbakekallingsstatus på Certificate.revocationcheck.com.

En kort historie om (problemene med) tilbakekallingskontroll

I de tidlige dagene av SSL var metoden CA-er å publisere sertifikatets tilbakekallingsstatus i offentlig tilgjengelige dokumenter sertifikat tilbakekall lister (CRL). En CRL er ganske enkelt en liste over alle sertifikater som en CA noen gang har opphevet før utløpet. CA-er publiserte periodisk den siste versjonen av CRL-ene, som nettlesere ble pålagt å konsultere med før du hver HTTPS-tilkobling.

Naturligvis som HTTPS (og SSL /TLS) adopsjonen økte med årene, det samme gjorde størrelsen på de publiserte CRL-ene. Kravet om å måtte laste ned og analysere en stor CRL før hver tilkobling påla et stadig økende nettverk. Det ble raskt tydelig at CRL-metoden ikke skaleres bra.

For å dempe disse skaleringsproblemene designet og implementerte nettlesere og CAer Online sertifikatstatus protokoll (OCSP). Offentlige klarerte CAer, som f.eks SSL.com, oppretthold nå enkle HTTP-servere som heter OCSP-svarere. Nettlesere kan nå kontakte en responder for å be om tilbakekallingsstatusen til et enkelt sertifikat utstedt av CA, i stedet for å måtte anskaffe og behandle hele CRL.

OCSP-respondere signerer svarene sine med CAs private signeringsnøkkel, og nettlesere kan bekrefte at tilbakekallingsstatusen de mottok faktisk ble generert av den faktiske CA.

Dessverre, selv om OCSP virket som en effektiv løsning i begynnelsen, har den nye protokollen vist seg å ha noen praktiske problemer med ytelse, sikkerhet og personvern.

Ytelsesproblemer

Å kontakte en responder for hvert sertifikat nettleseren møter, betyr at nettlesere må utføre en ekstra HTTP-forespørsel for hver nye HTTPS-tilkobling. Dette nettverksoverheadset var merkbart for brukere, spesielt på sider som inneholder tredjepartsinnhold lagret i eksterne innholdsdistribusjonsservere (som hver kan ha ett eller flere sertifikater på plass).

respons er et essensielt prinsipp for god brukergrensesnittdesign. Lange forsinkelser kan være en viktig årsak til bruker frustrasjon, og kan føre til at brukere tror nettstedet ditt ikke fungerer, eller at deres inngangsbevegelse har blitt ignorert.

Hva mer, mange studier tidligere har koblet rask sidehastighet og respons med forbedret SEO og økt konverteringsfrekvens. Faktisk har Amazon beregnet at en forsinkelse på bare ett sekund kan koste dem omtrent $1.6 milliarder årlig.

(Hvis du vil ha mer informasjon om hvordan sidehastighet påvirker nettstedet ditt og foreslåtte optimaliseringer, kan du ta en titt på vår Artikkel beskriver hvordan å fjerne blandet innhold fra nettstedet ditt vil forbedre ytelsen.)

Sikkerhetsspørsmål

Det er også viktige sikkerhetsproblemer med OCSP. At flertallet av praktiske OCSP-implementeringer ikke var pålitelige nok (verken på grunn av nettverksforsinkelse, eller konfigurasjons- eller applikasjonsfeil), motiverte nettlesere og annen klientprogramvare til å implementere OCSP-innsjekking soft-fail modus.

Dette betyr at hvis en OCSP-server ikke kan nås eller avbrytes når den gir svar, vil nettlesere gjøre det anser sertifikatet som gyldig og fortsett med HTTPS-tilkoblingen uansett.

Begrunnelsen bak dette er at siden en OCSP-server potensielt kan betjene millioner av nettsteder og det er mulig for en OCSP-server å mislykkes når som helst, vil det å ødelegge tilkoblingen på hver OCSP-feil forstyrre nettopplevelsen til millioner av brukere. Selv om OCSP-serveren er i drift, men det tar lang tid å svare, øker dette opplevd etterslep og bruker frustrasjon.

Man-i-midten (MITM) angripere har vært kjent for å utnytte denne oppførselen ved å blokkere alle forbindelser til OCSP-respondere, noe som effektivt betyr at de kan bruke et stjålet sertifikat og nøkkelpar for et ondsinnet nettsted, uavhengig av sertifikatets tilbakekallingsstatus.

Privatlivs problemer

Til slutt, siden et sertifikat er koblet til en nøkkel og et domenenavn, og nettlesere ber om tilbakekallingsstatus før hver nye HTTPS-forbindelse, betyr dette at nettlesere lekker en betydelig del av brukernes nettlogg til OCSP-respondere.

Offentlige pålitelige CA-er er selvfølgelig ikke ondsinnede organisasjoner som ønsker å kompromittere brukernes personvern. (Anerkjente CAer prøver alltid å gjøre det aktivt beskytte deres brukeres sikkerhet og personvern.) I tilfelle kompromiss med en CAs OCSP-responder, kan data som utveksles med den ikke-pålitelige serveren, føre til avsløring av sensitiv og privat informasjon.

OCSP stifting til unnsetning

For å avhjelpe disse problemene kom nettlesere og CA-er med en ny metode for å bestemme sertifikatets status, kalt OCSP-stifting. OCSP-stifting lar webservere (i stedet for nettlesere) skaffe signerte OCSP-svar for sertifikatene sine, som kan bufres i opptil 7 dager.

Servere inkluderer (eller stift) hurtigbufrede OCSP-svar i HTTPS-svarene ved siden av selve SSL-sertifikatet. På denne måten kan nettlesere verifisere CA-signaturen på OCSP-svaret og være sikre på at sertifikatet ikke er tilbakekalt før den sikre forbindelsen er opprettet og uten å måtte utføre den dyre tilleggsforespørselen til OCSP-serveren selv.

OCSP-stifting er en enkel, men veldig effektiv løsning på problemene nevnt over. Servere kan hente de hurtigbufrede OCSP-svarene på egen tid, noe som fjerner ytelseskostnadene som er pålagt av CRL-er og OCSP, samt de tilhørende personvernhensynene.

OCSP-stifting i seg selv løser imidlertid ikke OCSPs soft-fail-sikkerhetsproblem helt. Siden stifting er implementert på serveren, kan nettlesere ikke vite om en server faktisk støtter stifting eller ikke.

Som en konsekvens kan MITM-angripere med et stjålet (men tilbakekalt) sertifikat utføre et nedgraderingsangrep ved å servere sertifikatet uten OCSP-stifting. En ofres nettleser er ikke i stand til å bekrefte om serveren faktisk støtter stifting, og fortsette å spørre OCSP-responderen slik de normalt ville gjort.

MITM-angripere kan da ganske enkelt blokkere denne OCSP-spørringen og effektivt tvinge nettlesere til å godta sertifikatet som gyldig.

OCSP må stifte

Dette angrepet motiverte CA-er og nettleserleverandører til å introdusere en utvidelse for SSL-sertifikater, definert i RFC 7633, ofte kalt OCSP Må-Staple (selv om RFC i seg selv ikke nevner dette navnet, noe som kan forårsake forvirring.) Dette mandater ganske enkelt OCSP-stifting for sertifikatet. Hvis en nettleser møter et sertifikat med denne utvidelsen som brukes uten OCSP-stifting, vil det bli avvist. OCSP Must-Staple reduserer det nevnte nedgraderingsangrepet, og det reduserer også unødvendig trafikk til CAs OCSP-respondere, noe som også kan bidra til å forbedre OCSP-ytelsen generelt.

Hvis du er interessert i å aktivere OCSP Must-Staple-utvidelsen i sertifikatene dine, kan du kontakte en av våre supportagenter på support@ssl.com for mer informasjon.

Aktiver OCSP-stifting på serveren din

Følgende seksjoner inneholder instruksjoner om hvordan du aktiverer OCSP-stifting i din side for å spare deg for problemer med å slå dette opp Apache og Nginx miljøer:

Apache

For å aktivere OCSP-stifting i din Apache server, vennligst legg til følgende linjer i serverens konfigurasjonsfil.

# OCSP stifting, bare i httpd 2.3.3 og senere SSLUseStapling på SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)

Nginx

For å aktivere OCSP-stifting i din Nginx server, vennligst legg til følgende tekst i serverens konfigurasjonsfil.

# OCSP stifting --- # hent OCSP poster fra URL i ssl_certificate og cache dem ssl_stapling på; ssl_stapling_verify på;

konklusjonen

Internett er et intrikat nettverk av avhengige komponenter, som alle (vanligvis) jobber i harmoni for å gi en sømløs surfingopplevelse. Systemets stadig økende kompleksitet skaper imidlertid en stadig utvidende angrepflate og gjør det mulig å utvikle og utføre nye nettverksangrep.

Det store antallet av komponentene øker naturlig nok ventetid og medfører forsinkelser, noe som betyr at virksomheter må finne måter å forbedre sikkerheten uten å påvirke brukeropplevelsen. Aktivering av OCSP-stifting vil gi deg den sjeldne muligheten til å forbedre sikkerheten og ytelse for nettstedet ditt på samme tid.

Som alltid svarer vi gjerne dine spørsmål angående stifting av OCSP eller andre problemer - bare send oss ​​e-post på support@ssl.com.

Abonner på SSL.coms nyhetsbrev

Ikke gå glipp av nye artikler og oppdateringer fra SSL.com

Hold deg informert og sikker

SSL.com er en global leder innen cybersikkerhet, PKI og digitale sertifikater. Registrer deg for å motta de siste bransjenyhetene, tipsene og produktkunngjøringene fra SSL.com.

Vi vil gjerne ha tilbakemeldinger

Ta vår spørreundersøkelse og fortell oss dine tanker om ditt nylige kjøp.