Introductie
HTTPS (via SSL /TLS) toepassingen codering met openbare sleutel om te voorkomen dat browsercommunicatie wordt gelezen of gewijzigd tijdens verzending via internet. Servers bieden bezoekende browsers een openbare sleutel die wordt gebruikt om een gecodeerde verbinding tot stand te brengen voor alle volgende gegevensuitwisselingen.
Echter, gewoon een ontvangen werkzaam publieke sleutel alleen garandeert niet dat deze (en bij uitbreiding de server) inderdaad eigendom is van de juiste afstandsbediening onderwerpen (dwz persoon, bedrijf of organisatie). Man-in-the-middle aanvallers kunnen netwerken manipuleren om hun eigen sleutels te bedienen, waardoor elke communicatie in gevaar komt.
Browsers voorkomen dit door authenticeren HTTPS-servers gebruiken certificaten, dat zijn digitale documenten die binden een openbare sleutel voor een individueel onderwerp. De binding wordt bevestigd door een vertrouwde persoon Certificeringsinstantie (CA) zoals SSL.com verifieer de identiteit van potentiële certificaathouders via geautomatiseerde en handmatige controles op basis van gekwalificeerde databases.
Deze vertrouwensrelatie betekent dat de veiligheid van webgebruikers niet absoluut is; het vereist eerder dat gebruikers browsers en CA's vertrouwen om hun veiligheid te beschermen. Daarom denken we dat het in het belang van elke gebruiker is om een basiskennis te hebben van hoe certificaatvalidatie werkt.
Merk op dat het certificaatvalidatieproces (in detail beschreven in standaarddocument RFC 5280) is nogal ingewikkeld. In dit artikel zullen we proberen u langs één pad te leiden (een browser die de SSL /TLS certificaat) en navigeer langs complexe details die voor de meeste gebruikers niet van belang zijn.
Certificaten en het X.509-formaat
Certificaten zijn in alle opzichten digitale bestanden, wat betekent dat ze een bestandsformaat moeten volgen om informatie op te slaan (bijv. Handtekeningen, sleutels, uitgevers, enz.). Terwijl privé PKI configuraties kunnen elk formaat voor hun certificaten implementeren, openbaar vertrouwd PKIs (dwz degenen die door de browsers worden vertrouwd) moeten voldoen aan RFC 5280, waarvoor het gebruik van de X.509 v3 formaat.
Met X.509 v3 kunnen certificaten aanvullende gegevens bevatten, zoals gebruiksbeperkingen of beleidsinformatie extensies, waarbij elke extensie een van beide is kritisch or niet kritisch. Browsers kunnen ongeldige of niet-herkende niet-kritieke extensies negeren, maar ze moeten alle kritieke extensies verwerken en valideren.
Certificeringspaden en padverwerking
CA's gebruiken een privésleutel om alle uitgegeven certificaten cryptografisch te ondertekenen. Dergelijke handtekeningen kunnen onherroepelijk bewijzen dat een certificaat is afgegeven door een specifieke CA en dat het niet is gewijzigd nadat het was ondertekend.
CA's stellen het eigendom van hun ondertekeningssleutel vast door in het bezit te zijn van een zelf afgegeven certificaat (de wortel) voor de overeenkomstige openbare sleutel. CA's moeten strikt gecontroleerde en gecontroleerde procedures naleven om een root te creëren, beheren en gebruiken, en om blootstelling te minimaliseren, zullen ze normaal gesproken een root gebruiken om tussen- certificaten. Deze tussenproducten kunnen vervolgens worden gebruikt om de certificaten van hun klanten uit te geven.
Browsers worden geleverd met een ingebouwde lijst met vertrouwde roots. (Dit zijn roots van CA's die voldoen aan de strikte criteria van de browser voor opname.) Om een certificaat te verifiëren, verkrijgt een browser een reeks certificaten, die elk het volgende certificaat in de reeks hebben ondertekend, waardoor de root van de ondertekenende CA wordt verbonden met die van de server. certificaat.
Deze reeks certificaten wordt a genoemd certificeringspad. De wortel van het pad wordt een vertrouw anker en het servercertificaat heet het blad or eind entiteit certificaat.
Pad constructie
Vaak moeten browsers meerdere certificeringspaden overwegen totdat ze een geldig pad voor een bepaald certificaat kunnen vinden. Hoewel een pad certificaten kan bevatten die op de juiste manier aan een bekend anker zijn gekoppeld, kan het pad zelf worden geweigerd vanwege beperkingen op padlengte, domeinnaam, certificaatgebruik of beleid.
Het bouwen en evalueren van alle mogelijke paden is een kostbaar proces dat wordt uitgevoerd voor elk nieuw certificaat dat een browser tegenkomt. Browsers hebben verschillende optimalisaties geïmplementeerd om het aantal afgewezen kandidaatpaden te minimaliseren, maar het verdiepen in dergelijke details valt ver buiten het bestek van dit artikel.
Padvalidatie
Nadat een kandidaat-certificeringspad is samengesteld, valideren browsers dit met behulp van de informatie in de certificaten. Een pad is geldig als browsers cryptografisch kunnen bewijzen dat, beginnend bij een certificaat dat rechtstreeks is ondertekend door een trust anchor, de bijbehorende privésleutel van elk certificaat werd gebruikt om de volgende in het pad uit te geven, helemaal tot aan het leaf-certificaat.
Algoritme voor certificeringspad
RFC 5280 beschrijft een standaard algoritme die browsers volgen om een certificeringspad van X.509-certificaten te valideren.
In feite doorlopen browsers alle certificaten in het pad, beginnend met het vertrouwensanker (dwz het basiscertificaat), waarbij de basisinformatie en kritieke extensies van elk certificaat worden gevalideerd.
Als de procedure zonder fouten eindigt met het laatste certificaat in het pad, wordt het pad als geldig geaccepteerd. Als er fouten worden geproduceerd, wordt het pad gemarkeerd als ongeldig.
Basis certificaatverwerking
Ongeacht eventuele extensies, moeten browsers altijd de basiscertificaatgegevens zoals de handtekening of de uitgever verifiëren. De volgende secties tonen de reeks controles die browsers uitvoeren.
1. De browser controleert de integriteit van het certificaat
De handtekening op het certificaat kan worden geverifieerd met behulp van normale openbare sleutelcryptografie. Als de handtekening ongeldig is, wordt het certificaat geacht te zijn gewijzigd na afgifte en wordt het daarom afgewezen.
2. De browser controleert de geldigheid van het certificaat
Een certificaat geldigheidsduur is het tijdsinterval waarin de ondertekenende CA garandeert dat hij informatie over zijn status zal bewaren. Browsers weigeren certificaten met een geldigheidsperiode die eindigt vóór of begint na de datum en tijd van de validatiecontrole.
3. De browser controleert de intrekkingsstatus van het certificaat
Wanneer een certificaat wordt afgegeven, wordt verwacht dat het gedurende de gehele geldigheidsperiode in gebruik is. Natuurlijk kunnen verschillende omstandigheden ertoe leiden dat een certificaat ongeldig wordt voordat het op natuurlijke wijze verloopt.
Dergelijke omstandigheden kunnen een onderwerp zijn dat zijn naam verandert of een vermoedelijke inbreuk op zijn privésleutel. In dergelijke gevallen moet een CA het bijbehorende certificaat intrekken, en gebruikers vertrouwen ook op een CA om browsers op de hoogte te stellen van de intrekkingsstatus van hun certificaten.
RFC 5280 beveelt aan dat CA's voor dit doel intrekkingslijsten gebruiken.
Certificaatintrekkingslijsten (CRL)
CA's geven periodiek een ondertekende, tijdgestempelde lijst met ingetrokken certificaten uit, genaamd a certificaatintrekkingslijst (CRL). CRL's worden gedistribueerd in openbaar beschikbare repositories en browsers kunnen de meest recente CRL van de CA verkrijgen en raadplegen bij het valideren van een certificaat.
Een minpunt van deze methode is dat de granulariteit van de herroeping in de tijd beperkt is tot de CRL-uitgifteperiode. Een browser wordt pas op de hoogte gesteld van een intrekking nadat alle momenteel uitgegeven CRL's zijn gepland om te worden bijgewerkt. Afhankelijk van het beleid van de ondertekenende CA kan dit een uur, een dag of zelfs een week duren.
Online Certificaat Status Protocol (OCSP)
Er zijn andere alternatieve methoden voor het verkrijgen van informatie over de intrekkingsstatus, waarvan de meest populaire de Online certificaatstatusprotocol (OCSP).
Beschreven in standaarddocument RFC6960Met OCSP kan een browser de intrekkingsstatus van een specifiek certificaat opvragen bij een online OCSP-server (ook wel een antwoorden). Indien correct geconfigureerd, is OCSP veel directer en vermijdt het het hierboven genoemde CRL-update-latentieprobleem. In aanvulling op, OCSP-nieten verbetert prestaties en snelheid.
4. De browser verifieert de uitgever
Certificaten worden normaal gesproken geassocieerd met twee entiteiten:
- De emittent, wat de entiteit is die de ondertekeningssleutel bezit en
- De onderwerpen, die verwijst naar de eigenaar van de openbare sleutel die het certificaat verifieert.
Browsers controleren of het emittent veld is hetzelfde als de onderwerpen veld van het vorige certificaat in het pad. Voor extra beveiliging, de meeste PKI implementaties controleren ook of de sleutel van de uitgever dezelfde is als de sleutel die het huidige certificaat heeft ondertekend. (Merk op dat dit niet waar is voor het trust-anker, aangezien roots zelf zijn uitgegeven, dwz ze hebben dezelfde uitgever en hetzelfde onderwerp.)
Beperking van verwerking
Met de X.509 v3-indeling kan een CA beperkingen of beperkingen definiëren voor de manier waarop elk certificaat wordt gevalideerd en gebruikt als essentiële extensies. Elk certificaat in het pad kan aanvullende beperkingen opleggen waaraan alle volgende certificaten moeten voldoen.
Certificaatbeperkingen hebben zelden invloed op de gemiddelde internetgebruiker, hoewel ze veel voorkomen in zakelijke SSL-oplossingen. Functionele beperkingen kunnen verschillende operationele doeleinden dienen, maar hun belangrijkste gebruik is het wegnemen van bekende beveiligingsproblemen.
5. De browser controleert naambeperkingen
Een particuliere (maar door het publiek vertrouwde) tussenliggende CA met de juiste naambeperkingen kan een organisatie fijnmazige controle bieden over certificaatbeheer en uitgifte. Certificaten kunnen worden beperkt tot een specifiek domein of domeinboom (dwz inclusief subdomeinen) voor de domeinnaam van een bedrijf of organisatie. Naamsbeperkingen worden vaak gebruikt voor tussenliggende CA-certificaten die zijn aangeschaft bij een publiekelijk vertrouwde CA om te voorkomen dat de tussenliggende CA perfect geldige certificaten uitgeeft voor domeinen van derden (bijv. google.com).
6. De browser controleert beleidsbeperkingen
Een certificaatbeleid is een juridisch document dat door een certificeringsinstantie wordt gepubliceerd en waarin de procedures worden beschreven die zij volgen om hun certificaten af te geven en te beheren. CA's kunnen een certificaat afgeven onder een of meer beleidsregels, en links naar deze zijn opgenomen in elk uitgegeven certificaat, zodat vertrouwende partijen dit beleid kunnen evalueren voordat ze besluiten dat certificaat te vertrouwen.
Om juridische en operationele redenen kunnen certificaten beperkingen opleggen aan het beleid waaraan ze kunnen worden onderworpen. Als blijkt dat een certificaat kritische beleidsbeperkingen bevat, moeten browsers deze valideren voordat ze verder kunnen gaan. (Kritieke beleidsbeperkingen worden echter zelden in de echte wereld aangetroffen en zullen daarom voor de rest van dit artikel worden genegeerd.)
7. De browser controleert basisbeperkingen (ook bekend als padlengte)
Met de X.509 v3-indeling kunnen uitgevers de maximale padlengte definiëren die een certificaat kan ondersteunen. Dit geeft controle over hoe ver elk certificaat in een certificeringspad kan worden geplaatst. Dit is eigenlijk belangrijk - browsers negeerden de lengte van het certificeringspad totdat een onderzoeker het aantoonde, in een 2009 presentatie, hoe hij het leaf-certificaat van zijn website gebruikte om een geldig certificaat voor een grote e-commercewebsite te vervalsen.
8. De browser controleert het sleutelgebruik
De extensie "sleutelgebruik" vermeldt het doel van de sleutel in het certificaat. Voorbeelden van dergelijke doeleinden zijn onder meer versleuteling, handtekeningen, ondertekening van certificaten, enzovoort. Browsers weigeren certificaten die hun sleutelgebruiksbeperkingen schenden, zoals het tegenkomen van een servercertificaat met een sleutel die alleen bedoeld is voor het ondertekenen van CRL.
9. De browser gaat door met het verwerken van alle resterende kritieke extensies
Na het verwerken van de bovengenoemde extensies, gaan browsers door met het valideren van alle resterende extensies die door het huidige certificaat als kritiek worden bestempeld, voordat ze doorgaan naar de volgende. Als een browser het leaf-certificaat van een pad zonder fouten bereikt, wordt het pad als geldig geaccepteerd. Als er fouten worden gemaakt, wordt het pad gemarkeerd als ongeldig en wordt er geen beveiligde verbinding tot stand gebracht.
Conclusie
Het World Wide Web is een complex systeem van onderling verbonden en constant evoluerende bewegende delen. Browserbeveiliging is dus geen opgelost probleem en we hopen dat dit artikel enig inzicht heeft gegeven in de complexiteit van zelfs het ene onderdeel dat we hier hebben bekeken. Vertrouwen speelt een belangrijke rol bij het veilig houden van u online, en daarom raden we u aan meer te informeren over het certificaatbeleid van uw CA. (Voel je vrij om te herzien SSL.com's beleid hier, in feite.)
Bedankt voor het kiezen van SSL.com, waar wij geloven dat veiliger Internet is een beter Internet.
