Introductie
Wanneer een gebruiker uw HTTPS-website bezoekt, moet deze reageren met een werkende publieke sleutel, en een geldig SSL-certificaat dat de sleutel aan uw identiteit koppelt, als persoon, bedrijf of organisatie. Certificaten worden altijd uitgegeven met een vooraf gedefinieerde vervaldatum die is opgenomen in het ondertekende certificaat zelf, en browsers controleren altijd de vervaldatum en weigeren elk verlopen certificaat.
In bepaalde gevallen moet een certificaat echter als ongeldig worden gemarkeerd (en vertrouwen op die certificaten moet dat zijn herroepen) vaardigheden het verloopt. Bekende voorbeelden zijn een servereigenaar die het bewijs heeft (of simpelweg vermoedt) dat zijn privésleutel is aangetast (dat wil zeggen dat deze is verloren, gestolen of vernietigd), aangezien een derde partij die deze privésleutel bezit in wezen alle beveiligingsmaatregelen van het browsernetwerk kan omzeilen.
Als gevolg hiervan waren browserleveranciers vereist publiekelijk vertrouwd certificeringsinstanties (CA's) om ten minste één methode te implementeren om zowel problematische certificaten in te trekken als om browsers op de hoogte te stellen om deze ingetrokken certificaten te weigeren.
Een korte geschiedenis van (de problemen van) intrekkingscontrole
In de begindagen van SSL was de methode die CA's gebruikten, het publiceren van hun certificaatintrekkingsstatus in openbaar toegankelijke documenten die werden genoemd lijsten met ingetrokken certificaten (CRL). Een CRL is gewoon een lijst met alle certificaten die een CA ooit heeft ingetrokken voordat ze vervallen. CA's publiceerden periodiek de nieuwste versie van hun CRL's, waarmee browsers moesten overleggen vaardigheden elke HTTPS-verbinding.
Uiteraard als HTTPS (en SSL /TLS) de adoptie is in de loop van de jaren toegenomen, evenals de omvang van de gepubliceerde CRL's. De vereiste om een grote CRL te moeten downloaden en ontleden vóór elke verbinding zorgde voor een steeds grotere netwerkoverhead. Al snel bleek dat de CRL-methode niet goed schaalde.
Om deze schaalproblemen te verminderen, hebben browsers en CA's de ontworpen en geïmplementeerd Online certificaatstatusprotocol (OCSP). Openbaar vertrouwde CA's, zoals SSL.com, onderhouden nu eenvoudige HTTP-servers genaamd OCSP-responders. Browsers konden nu contact opnemen met een responder om de intrekkingsstatus van een enkel door de CA uitgegeven certificaat aan te vragen, in plaats van dat ze de hele CRL moesten verwerven en verwerken.
OCSP-responders ondertekenen hun antwoorden met de persoonlijke ondertekeningssleutel van de CA en browsers kunnen controleren of de intrekkingsstatus die ze hebben ontvangen inderdaad is gegenereerd door de daadwerkelijke CA.
Hoewel OCSP in eerste instantie een effectieve oplossing leek, heeft het helaas bewezen dat het een aantal praktische prestatie-, beveiligings- en privacyproblemen heeft.
Prestatieproblemen
Contact opnemen met een responder voor elk certificaat dat de browser tegenkomt, betekent dat browsers voor elke nieuwe HTTPS-verbinding een extra HTTP-verzoek moeten uitvoeren. Deze netwerkoverhead was waarneembaar voor gebruikers, vooral op pagina's met inhoud van derden die is opgeslagen op externe inhoudsdistributieservers (die elk een of meer certificaten kunnen hebben).
Responsiviteit is een essentieel principe van een goed gebruikersinterfaceontwerp. Lange vertragingen kunnen een grote oorzaak zijn van frustratie bij gebruikers en kunnen ertoe leiden dat gebruikers denken dat uw website niet werkt of dat hun invoergebaar is genegeerd.
Wat meer is, veel studies in het verleden hebben snelle laadsnelheid en reactievermogen gekoppeld aan verbeterde SEO en hogere conversieratio's. Amazon heeft zelfs berekend dat een vertraging van slechts één seconde hen ongeveer kan kosten $1.6 miljard jaarlijks.
(Voor meer informatie over hoe de laadsnelheid van de pagina uw website beïnvloedt en voorgestelde optimalisaties, kunt u onze raadplegen dit artikel beschrijven hoe het verwijderen van gemengde inhoud van uw website de prestaties zal verbeteren.)
Veiligheidsvraagstukken
Er zijn ook belangrijke beveiligingsproblemen bij OCSP. Het feit dat de meeste praktische OCSP-implementaties niet betrouwbaar genoeg waren (vanwege netwerkvertraging of configuratie- of toepassingsfouten), motiveerden browsers en andere clientsoftware om OCSP-inchecken te implementeren zachte mislukking modus.
Dit betekent dat als een OCSP-server niet kan worden bereikt of een time-out krijgt tijdens het geven van zijn reactie, browsers dat wel zullen doen beschouw het certificaat als geldig en ga toch door met de HTTPS-verbinding.
De redenering hierachter is dat aangezien een OCSP-server potentieel miljoenen websites kan bedienen en het mogelijk is dat een OCSP-server op elk moment faalt, zou het verbreken van de verbinding bij elke OCSP-storing de browse-ervaring van miljoenen gebruikers verstoren. Zelfs als de OCSP-server werkt, maar het duurt lang om te antwoorden, draagt dit bij aan de waargenomen vertraging en frustratie bij de gebruiker.
Man-in-the-middle (MITM) Van aanvallers is bekend dat ze dit gedrag misbruiken door te blokkeren allen verbindingen met OCSP-responders, wat in feite betekent dat ze een gestolen certificaat en sleutelpaar kunnen gebruiken voor een kwaadwillende site, ongeacht de intrekkingsstatus van het certificaat.
Priveproblemen
Ten slotte, aangezien een certificaat is gekoppeld aan een sleutel en een domeinnaam, en browsers de intrekkingsstatus opvragen voor elke nieuwe HTTPS-verbinding, betekent dit dat browsers een aanzienlijk deel van de webgeschiedenis van hun gebruikers lekken naar OCSP-responders.
Openbaar vertrouwde CA's zijn natuurlijk geen kwaadwillende organisaties die de privacy van gebruikers in gevaar willen brengen. (Gerenommeerde CA's proberen dit altijd actief te doen beschermen de veiligheid en privacy van hun gebruikers.) In het geval dat de OCSP-responder van een CA in gevaar wordt gebracht, kunnen gegevens die worden uitgewisseld met die niet-vertrouwde server, leiden tot het vrijgeven van gevoelige en privé-informatie.
OCSP Nieten schiet te hulp
Om deze problemen te verminderen, bedachten browsers en CA's een nieuwe methode om de status van een certificaat te bepalen, genaamd OCSP-nieten. Met OCSP-nieten kunnen webservers (in plaats van browsers) ondertekende OCSP-antwoorden krijgen voor hun certificaten, die maximaal 7 dagen in de cache kunnen worden opgeslagen.
Servers omvatten (of kram) het in de cache opgeslagen OCSP-antwoord in hun HTTPS-antwoorden naast het SSL-certificaat zelf. Op deze manier kunnen browsers de handtekening van de CA op de OCSP-respons verifiëren en er zeker van zijn dat het certificaat niet is ingetrokken voordat de beveiligde verbinding tot stand is gebracht en zonder zelf het dure aanvullende verzoek aan de OCSP-server te hoeven uitvoeren.
OCSP-nieten is een eenvoudige maar zeer effectieve oplossing voor de bovengenoemde problemen. Servers kunnen de in het cachegeheugen opgeslagen OCSP-antwoorden in hun eigen tijd ophalen, waardoor de prestatie-overhead die wordt opgelegd door CRL's en OCSP, evenals de bijbehorende privacykwesties worden verwijderd.
OCSP-nieten op zichzelf lost echter het soft-fail-beveiligingsprobleem van OCSP niet volledig op. Aangezien nieten is geïmplementeerd in de server, kunnen browsers niet weten of een server daadwerkelijk Nieten ondersteunt of niet.
Als gevolg hiervan kunnen MITM-aanvallers met een gestolen (maar ingetrokken) certificaat een downgrade-aanval uitvoeren door het certificaat te leveren zonder OCSP-nieten. De browser van een slachtoffer kan niet bevestigen of de server daadwerkelijk nieten ondersteunt, en gaat door met het opvragen van de OCSP-responder zoals normaal.
MITM-aanvallers kunnen deze OCSP-query vervolgens eenvoudig blokkeren en browsers effectief dwingen het certificaat als geldig te accepteren.
OCSP moet nieten
Deze aanval motiveerde CA's en browserleveranciers om een extensie voor SSL-certificaten te introduceren, gedefinieerd in RFC 7633, gewoonlijk genoemd OCSP Moet nieten (hoewel de RFC zelf deze naam niet vermeldt, wat enige verwarring kan veroorzaken.) Dit vereist gewoon OCSP-nieten voor het certificaat. Als een browser een certificaat met deze extensie tegenkomt dat wordt gebruikt zonder OCSP-nieten, wordt het geweigerd. OCSP Must-Staple beperkt de bovengenoemde downgrade-aanval en vermindert ook onnodig verkeer naar de OCSP-responders van de CA, wat ook kan helpen de algehele OCSP-prestaties te verbeteren.
Als u geïnteresseerd bent in het inschakelen van de OCSP Must-Staple-extensie in uw certificaten, neem dan contact op met een van onze ondersteuningsmedewerkers op support@ssl.com voor meer details.
Schakel OCSP Stapling in op uw server
Om u de moeite te besparen dit op te zoeken, bevatten de volgende secties instructies voor het inschakelen van OCSP Stapling in uw apache en Nginx omgevingen:
apache
Om OCSP-nieten in uw apache server, voeg de volgende regels toe aan het configuratiebestand van uw server.
# OCSP Stapling, alleen in httpd 2.3.3 en later SSLUseStapling op SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors van SSLStaplingCache shmcb: / var / run / ocsp (128000)
Nginx
Om OCSP-nieten in uw Nginx server, voeg dan de volgende tekst toe aan het configuratiebestand van uw server.
# OCSP Stapling --- # haal OCSP-records op van URL in ssl_certificate en sla ze op in ssl_stapling op; ssl_stapling_verify op;
Conclusie
Het web is een ingewikkeld netwerk van onderling afhankelijke componenten, die allemaal (meestal) in harmonie samenwerken om een naadloze browse-ervaring te bieden. De steeds toenemende complexiteit van dit systeem creëert echter een steeds groter wordend aanvalsoppervlak en maakt het mogelijk nieuwe netwerkaanvallen te bedenken en uit te voeren.
Het grote aantal componenten verhoogt natuurlijk de latentie en leidt tot vertragingen, wat betekent dat bedrijven manieren moeten vinden om de beveiliging te verbeteren zonder de gebruikerservaring te beïnvloeden. Als u OCSP-nieten inschakelt, krijgt u die zeldzame kans om de beveiliging te verbeteren en prestaties voor uw website tegelijkertijd.
Zoals altijd beantwoorden we graag uw vragen over OCSP-nieten of andere problemen - stuur ons een e-mail op support@ssl.com.
