Introduktion
Når en bruger besøger dit HTTPS-websted, skal den svare med en fungerende offentlig nøgle, og et gyldigt SSL-certifikat, der knytter nøglen til din identitet, enten som person, firma eller organisation. Certifikater udstedes altid med en foruddefineret udløbsdato, der er inkluderet i selve det underskrevne certifikat, og browsere kontrollerer altid udløbsdatoen og afviser ethvert udløbet certifikat.
I visse tilfælde skal et certifikat dog markeres som ugyldigt (og tillid til disse certifikater skal være tilbagekaldt) før den udløber. Almindelige eksempler inkluderer en serverejer, der har bevis (eller blot mistænker) for, at deres private nøgle blev kompromitteret (dvs. at den var mistet, stjålet eller ødelagt), da en tredjepart, der har denne private nøgle, i det væsentlige kan omgå alle browsernetværkets sikkerhedskontroller.
Som en konsekvens krævede browserudbydere offentligt betroet certifikatmyndigheder (CA'er) til at implementere mindst en metode til både at tilbagekalde problematiske certifikater og for at underrette browsere om at afvise disse tilbagekaldte certifikater.
En kort historie om (problemerne med) tilbagekaldelseskontrol
I de tidlige dage af SSL var den anvendte CA's metode til at offentliggøre deres status for tilbagekaldelse af certifikater i offentligt tilgængelige dokumenter, der blev kaldt lister med certifikat tilbagekaldelse (C.R.L.). En CRL er simpelthen en liste over alle de certifikater, som en CA nogensinde har tilbagekaldt før udløbet. CA'er offentliggjorde med jævne mellemrum den nyeste version af deres CRL'er, hvilke browsere skulle konsultere før hver HTTPS-forbindelse.
Naturligvis som HTTPS (og SSL /TLS) Adoption steg med årene, det samme gjorde størrelsen af de offentliggjorte CRL'er. Kravet om at skulle downloade og analysere en stor CRL før hver forbindelse pålagde et stadigt stigende netværksomkostning. Det viste sig hurtigt, at CRL-metoden ikke skaleres godt.
For at afbøde disse skaleringsproblemer designede og implementerede browsere og CA'er Online-certifikatstatusprotokol (OCSP). Offentligt tillidte CA'er, såsom SSL.com, vedligehold nu enkle HTTP-servere, der kaldes OCSP-respondere. Browsere kunne nu kontakte en responder for at anmode om tilbagekaldelsesstatus for et enkelt certifikat udstedt af CA i stedet for at skulle erhverve og behandle hele CRL.
OCSP-respondenter underskriver deres svar med CA's private signeringsnøgle, og browsere kan kontrollere, at den tilbagekaldelsesstatus, de modtog, faktisk blev genereret af den faktiske CA.
Desværre, selvom OCSP virket som en effektiv løsning i starten, har den nye protokol vist sig at have nogle praktiske problemer med hensyn til ydelse, sikkerhed og privatliv.
Problemer med ydeevne
At kontakte en responder for hvert certifikat, som browseren møder, betyder, at browsere skal udføre en ekstra HTTP-anmodning for hver nye HTTPS-forbindelse. Dette netværksomkostning var mærkbar for brugerne, især på sider, der indeholder tredjepartsindhold, der er gemt i eksterne indholdsfordelingsservere (som hver især kan have et eller flere certifikater på plads).
lydhørhed er et essentielt princip for god brugergrænsefladedesign. Lange forsinkelser kan være en væsentlig årsag til bruger frustration og kan føre til, at brugerne tror, at dit websted ikke fungerer, eller at deres inputbevægelse er ignoreret.
Hvad mere er, mange undersøgelser i fortiden har knyttet hurtig sidehastighed og reaktionsevne med forbedret SEO og øget konverteringsfrekvens. Faktisk har Amazon beregnet, at en forsinkelse på kun et sekund kan koste dem ca. $1.6 milliarder årligt.
(For flere detaljer om, hvordan sidehastighed påvirker dit websted og foreslåede optimeringer, se venligst vores artikel beskriver, hvordan fjernelse af blandet indhold fra dit websted forbedrer dets ydelse.)
Sikkerhedsspørgsmål
Der er også vigtige sikkerhedsproblemer med OCSP. At flertallet af praktiske OCSP-implementeringer ikke var pålidelige nok (hverken på grund af netværksforsinkelse eller konfigurations- eller applikationsfejl), motiverede browsere og anden klientsoftware til at implementere OCSP-kontrol blød-fejl mode.
Dette betyder, at hvis en OCSP-server ikke kan nås eller udløber tid, mens den giver sit svar, vil browsere gøre det betragt certifikatet som gyldigt og fortsæt alligevel med HTTPS-forbindelsen.
Årsagen bag dette er, at da en OCSP-server potentielt kan betjene millioner af websteder, og det er muligt for en OCSP-server at mislykkes på ethvert tidspunkt, ville det at forringe forbindelsen på enhver OCSP-fejl forstyrre browservirksomheden for millioner af brugere. Selv hvis OCSP-serveren fungerer, men det tager lang tid at svare, øger dette den opfattede forsinkelse og bruger frustration.
Mand-i-midten (MITM) angribere har været kendt for at udnytte denne opførsel ved at blokere alle forbindelser til OCSP-respondenter, hvilket effektivt betyder, at de kan bruge et stjålet certifikat og nøglepar til et ondsindet websted, uanset certifikatets tilbagekaldelsesstatus.
Privatlivsproblemer
Endelig, da et certifikat er knyttet til en nøgle og et domænenavn, og browsere anmoder om tilbagekaldelsesstatus før hver nye HTTPS-forbindelse, betyder det, at browsere lækker en betydelig del af deres brugeres webhistorik til OCSP-respondenter.
Officielt betroede CA'er er naturligvis ikke ondsindede organisationer, der ønsker at kompromittere brugernes privatliv. (Anerkendte CA'er prøver altid aktivt at gøre det beskytte deres brugeres sikkerhed og privatliv.) I tilfælde af kompromis mellem en CA's OCSP-responder kan data, der udveksles med den ikke-tillidte server, føre til afsløring af følsomme og private oplysninger.
OCSP hæftning til redning
For at afbøde disse problemer kom browsere og CA'er med en ny metode til at bestemme et certifikats status, kaldet OCSP hæftning. OCSP-hæftning giver webservere (i stedet for browsere) mulighed for at få underskrevne OCSP-svar til deres certifikater, der kan cache i op til 7 dage.
Servere inkluderer (eller hæftning) cache-OCSP-svar i deres HTTPS-svar sammen med selve SSL-certifikatet. På denne måde kan browsere verificere CAs-signaturen på OCSP-svaret og være sikre på, at certifikatet ikke er blevet tilbagekaldt, før den sikre forbindelse er etableret og uden at skulle udføre den dyre yderligere anmodning til OCSP-serveren selv.
OCSP hæftning er en enkel, men meget effektiv løsning på de ovennævnte problemer. Servere kan hente de cachelagrede OCSP-svar på deres egen tid, hvilket fjerner den ydeevne, der er pålagt af CRL'er og OCSP, samt de ledsagende privatlivsproblemer.
OCSP-hæftning i sig selv løser imidlertid ikke OCSP's soft-fail sikkerhedsproblem fuldstændigt. Da hæftning er implementeret på serveren, kan browsere ikke vide, om en server faktisk understøtter hæftning eller ej.
Som en konsekvens kan MITM-angribere med et stjålet (men tilbagekaldt) certifikat udføre et nedgraderingsangreb ved at betjene certifikatet uden OCSP-hæftning. En ofres browser er ikke i stand til at bekræfte, om serveren faktisk understøtter hæftning, og fortsæt med at spørge OCSP-responderen, som de normalt ville.
MITM-angribere kan derefter blot blokere denne OCSP-forespørgsel og effektivt tvinge browsere til at acceptere certifikatet som gyldigt.
OCSP skal hæfteklammer
Dette angreb motiverede CA'er og browserudbydere til at introducere en udvidelse til SSL-certifikater, defineret i RFC 7633, almindeligvis kaldet OCSP Skal hæfteklammer (selvom RFC selv ikke nævner dette navn, hvilket kan forårsage en vis forvirring.) Dette pålægger simpelthen OCSP hæftning til certifikatet. Hvis en browser støder på et certifikat med denne udvidelse, der bruges uden OCSP-hæftning, afvises det. OCSP Must-Staple afbød det ovennævnte nedgraderingsangreb, og det reducerer også unødvendig trafik til CA's OCSP-respondenter, hvilket også kan hjælpe med at forbedre den samlede OCSP-ydeevne.
Hvis du er interesseret i at aktivere OCSP Must-Staple-udvidelsen i dine certifikater, skal du kontakte en af vores supportagenter på support@ssl.com for flere detaljer.
Aktivér OCSP hæftning på din server
For at spare dig for besværet med at slå dette op, indeholder følgende afsnit instruktioner om, hvordan du aktiverer OCSP hæftning i din Apache , Nginx miljøer:
Apache
Sådan aktiveres OCSP-hæftning i din Apache server, skal du tilføje følgende linjer i din servers konfigurationsfil.
# OCSP hæftning, kun i httpd 2.3.3 og senere SSLUseStapling på SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)
Nginx
Sådan aktiveres OCSP-hæftning i din Nginx server, skal du tilføje følgende tekst i din servers konfigurationsfil.
# OCSP Hæftning --- # hent OCSP-poster fra URL i ssl_certificate og cache dem ssl_stapling på; ssl_stapling_verify on;
Konklusion
Internettet er et indviklet netværk af indbyrdes afhængige komponenter, der alle (normalt) arbejder i harmoni for at give en problemfri browsingoplevelse. Systemets stadigt stigende kompleksitet skaber imidlertid en stadigt voksende angreboverflade og gør det muligt at udtænke og udføre nye netværksangreb.
Det store antal af komponenterne øger naturligvis latenstiden og medfører forsinkelser, hvilket betyder, at virksomheder er nødt til at finde måder at forbedre sikkerheden uden at påvirke brugeroplevelsen. Aktivering af OCSP hæftning giver dig den sjældne mulighed for at forbedre sikkerheden , ydeevne til dit websted på samme tid.
Som altid svarer vi glade for dine spørgsmål vedrørende OCSP-hæftning eller andre problemer - bare send os e-mail på support@ssl.com.
