Introduktion
HTTPS (via SSL /TLS) bruger offentlig nøglekryptering for at beskytte browserkommunikation mod at blive læst eller ændret under transit over internettet. Servere giver besøgende browsere en offentlig nøgle, der bruges til at etablere en krypteret forbindelse til alle efterfølgende dataudveksling.
Men bare at modtage en arbejder offentlig nøgle alene garanterer ikke, at den (og ved udvidelse af serveren) faktisk ejes af den rigtige fjernbetjening emne (dvs. person, virksomhed eller organisation). Man-in-the-middle angribere kan manipulere netværk for at tjene deres egne nøgler og derved kompromittere enhver kommunikation.
Browsere forhindrer dette ved godkendende HTTPS-servere bruger certifikater, som er digitale dokumenter, der binde en offentlig nøgle til et individuelt emne. Bindingen hævdes ved at have en betroet Certificeringsmyndighed (CA) såsom SSL.com verificere identiteten af potentielle certifikatejere via automatiseret og manuel kontrol over kvalificerede databaser.
Dette tillidsforhold betyder, at webbrugernes sikkerhed ikke er absolut; snarere kræver det, at brugerne stoler på browsere og CA'er for at beskytte deres sikkerhed. Derfor mener vi, at det er i enhver brugers interesse at have en grundlæggende forståelse af, hvordan certifikatvalidering fungerer.
Bemærk, at certifikatvalideringsprocessen (beskrevet detaljeret i standarddokumentet) RFC 5280) er ganske indviklet. I denne artikel vil vi forsøge at gå dig ad en sti (en browser, der validerer en værts SSL /TLS certifikat) og navigere forbi komplekse detaljer, der er ubetydelige for de fleste brugere.
Certifikater og X.509-format
Certifikater er digitale filer i enhver henseende, hvilket betyder, at de skal følge et filformat for at gemme information (f.eks. Underskrifter, nøgler, udstedere osv.). Mens privat PKI konfigurationer kan implementere ethvert format til deres certifikater, der er offentligt tillid til PKIs (dvs. dem, som browsere har tillid til) skal være i overensstemmelse med RFC 5280, som kræver brug af X.509 v3 format.
X.509 v3 giver certifikater mulighed for at inkludere yderligere data, f.eks. Brugsbegrænsninger eller politikoplysninger, som udvidelser, med hver udvidelse enten kritisk or ukritisk. Browsere kan ignorere ugyldige eller ikke-anerkendte ikke-kritiske udvidelser, men de er forpligtet til at behandle og validere alle kritiske udvidelser.
Certificeringsstier og sti-behandling
CA'er bruger en privat nøgle til at kryptografisk underskrive alle udstedte certifikater. Sådanne underskrifter kan uigenkaldeligt bevise, at et certifikat blev udstedt af en bestemt CA, og at det ikke blev ændret efter det blev underskrevet.
CA'er etablerer ejerskab af deres signaturnøgle ved at have et selvudstedt certifikat (kaldet rod) for den tilsvarende offentlige nøgle. CA'er skal overvåge stramt kontrollerede og reviderede procedurer for at oprette, styre og anvende en rod, og for at minimere eksponering vil normalt bruge en rod til at udstede mellemliggende certifikater. Disse mellemprodukter kan derefter bruges til at udstede deres kunders certifikater.
Browsere sendes med en indbygget liste over pålidelige rødder. (Disse er rødder fra CA'er, der har bestået browserens strenge kriterier for inkludering.) For at bekræfte et certifikat får en browser en sekvens af certifikater, hvor hver har underskrevet det næste certifikat i sekvensen, der forbinder den signerende CA's rod til serverens certifikat.
Denne sekvens af certifikater kaldes a certificeringssti. Stiens rod kaldes en tillidsanker og serverens certifikat kaldes blad or slut enhed certifikat.
Vejkonstruktion
Ofte skal browsere overveje flere certificeringsstier, indtil de kan finde en gyldig til et givet certifikat. Selvom en sti kan indeholde certifikater, der "sammenkædes" korrekt til et kendt anker, kan stien i sig selv afvises på grund af restriktioner på stillængde, domænenavn, certifikatbrug eller politik.
Konstruktion og evaluering af alle mulige stier er en kostbar proces, der udføres for hvert nyt certifikat, en browser støder på. Browsere har implementeret forskellige optimeringer for at minimere antallet af afviste kandidatstier, men at undersøge sådanne detaljer er langt uden for denne artikels rækkevidde.
Sti validering
Når en kandidatcertificeringssti er konstrueret, validerer browsere den ved hjælp af oplysningerne i certifikaterne. En sti er gyldig, hvis browsere kryptografisk kan bevise, at startende fra et certifikat direkte underskrevet af et tillidsanker, blev hvert certifikats tilsvarende private nøgle brugt til at udstede den næste i stien, helt ned til bladcertifikatet.
Godkendelsesalgoritme til certificeringssti
RFC 5280 beskriver a standard algoritme som browsere følger for at validere en certificeringssti for X.509-certifikater.
Grundlæggende gentages browsere gennem alle certifikater i stien startende med tillidsankeret (dvs. rodcertifikatet), hvilket validerer hvert certifikats grundlæggende information og kritiske udvidelser.
Hvis proceduren afsluttes med det sidste certifikat i stien uden fejl, accepteres stien som gyldig. Hvis der produceres fejl, markeres stien som ugyldig.
Grundlæggende certifikatbehandling
Uanset udvidelser skal browsere altid verificere grundlæggende certifikatoplysninger såsom signatur eller udsteder. De følgende sektioner viser rækkefølgen af kontroller, som browsere udfører.
1. Browseren verificerer certifikatets integritet
signatur på certifikatet kan verificeres ved hjælp af normal offentlig nøglekryptografi. Hvis underskriften er ugyldig, betragtes certifikatet som ændret efter udstedelsen og afvises derfor.
2. Browseren verificerer certifikatets gyldighed
Et certifikat gyldighedsperiode er det tidsinterval, i hvilket den underskrivende CA garanterer, at den opretholder oplysninger om dens status. Browsere afviser ethvert certifikat med en gyldighedsperiode, der slutter før eller starter efter datoen og tidspunktet for valideringskontrollen.
3. Browseren kontrollerer certifikatets tilbagekaldelsesstatus
Når der udstedes et certifikat, forventes det at være i brug i hele sin gyldighedsperiode. Naturligvis kan forskellige omstændigheder medføre, at et certifikat bliver ugyldigt, før det naturligvis udløber.
Sådanne omstændigheder kan omfatte et emne, der skifter navn eller et mistanke om kompromis med deres private nøgle. I tilfælde som denne skal en CA tilbagekalde det tilsvarende certifikat, og brugerne sætter også deres tillid til en CA for at underrette browsere om deres certifikaters tilbagekaldelsesstatus.
RFC 5280 anbefaler, at CA'er bruger tilbagekaldelseslister til dette formål.
Liste over tilbagekaldelse af certifikater (CRL)
CA'er udsteder med jævne mellemrum en underskrevet, tidsstemplet liste over tilbagekaldte certifikater kaldet a liste over tilbagekaldelse af certifikater (CRL). CRL'er distribueres i offentligt tilgængelige arkiver, og browsere kan erhverve og konsultere CA's seneste CRL, når de validerer et certifikat.
En fejl ved denne metode er, at tidsgranulariteten for tilbagekaldelse er begrænset til CRL-udstedelsesperioden. En browser får kun besked om tilbagekaldelse, efter at alle aktuelt udstedte CRL'er er planlagt til at blive opdateret. Afhængigt af den underskrevne CA's politik kan dette tage en time, dag eller endda op til en uge.
Online certifikatstatusprotokol (OCSP)
Der er andre alternative metoder til at få oplysninger om tilbagekaldelsesstatus, hvor de mest populære er Online-certifikatstatusprotokol (OCSP).
Beskrevet i standarddokument RFC6960, Lader OCSP en browser anmode om et specifikt certifikats tilbagekaldelsesstatus fra en online OCSP-server (også kaldet en gentage). Når OCSP er korrekt konfigureret, er det meget mere øjeblikkeligt og undgår ovennævnte CRL-opdaterings latency-problem. Ud over, OCSP hæftning forbedrer ydeevne og hastighed.
4. Browseren verificerer udstederen
Certifikater er normalt forbundet med to enheder:
- udsteder, som er den enhed, der ejer underskriftsnøglen og
- emne, der henviser til ejeren af den offentlige nøgle, som certifikatet godkender.
Browsere kontrollerer, at et certifikat er udsteder feltet er det samme som emne felt for det forrige certifikat i stien. For øget sikkerhed, mest PKI implementeringer verificerer også, at udsteders nøgle er den samme som nøglen, der underskrev det aktuelle certifikat. (Bemærk, at dette ikke gælder for tillidsankeret, da rødderne er selvudstedte - dvs. de har samme udsteder og emne.)
Behandling af begrænsninger
X.509 v3-format giver en CA mulighed for at definere begrænsninger eller begrænsninger for, hvordan hvert certifikat valideres og bruges som kritiske udvidelser. Hvert certifikat i stien kan indføre yderligere begrænsninger, som alle efterfølgende certifikater skal overholde.
Certifikatbegrænsninger påvirker sjældent den gennemsnitlige internetbruger, skønt de er ret almindelige i virksomhedens SSL-løsninger. Funktionelle begrænsninger kan tjene flere operationelle formål, men deres mest markante anvendelse er at afbøde kendte sikkerhedsmæssige problemer.
5. Browseren kontrollerer navnebegrænsninger
En privatejet (men offentligt betroet) mellemliggende CA med det relevante navnebegrænsninger kan give en organisation finkornet kontrol over certifikatstyring og udstedelse. Certifikater kan være begrænset til et bestemt domæne eller domænetræ (dvs. inklusive underdomæner) for en virksomheds eller organisations domænenavn. Navnebegrænsninger bruges ofte til mellemliggende CA-certifikater købt fra en offentligt betroet CA for at forhindre den mellemliggende CA i at udstede perfekt gyldige certifikater til tredjepartsdomæner (f.eks. google.com).
6. Browseren kontrollerer politikbegrænsninger
En certifikatpolitik er et juridisk dokument, der er offentliggjort af en CA, der officielt beskriver de procedurer, de følger for at udstede og administrere deres certifikater. CA'er udsteder muligvis et certifikat under en eller flere politikker, og links til disse er inkluderet i hvert udstedt certifikat, så de pålidelige parter kan evaluere disse politikker, inden de beslutter at stole på det certifikat.
Af juridiske og operationelle grunde kan certifikater indføre begrænsninger for, hvilke politikker de kan være underlagt. Hvis det konstateres, at et certifikat indeholder kritiske politiske begrænsninger, skal browsere validere dem, før de fortsætter. (Imidlertid forekommer sjældent kritiske politiske begrænsninger i den virkelige verden, og de vil derfor ikke ses bort fra resten af denne artikel.)
7. Browseren kontrollerer grundlæggende begrænsninger (alias sti-længde)
X.509 v3-formatet giver udstedere mulighed for at definere den maksimale kurslængde, som et certifikat kan understøtte. Dette giver kontrol over, hvor langt hvert certifikat kan placeres i en certificeringssti. Dette er faktisk vigtigt - browsere plejede at se bort fra certificeringsstiens længde, indtil en forsker demonstrerede i en 2009 præsentation, hvordan han brugte sit websteds bladcertifikat til at smede et gyldigt certifikat til et stort e-handelswebsted.
8. Browseren verificerer nøglebrug
Udvidelsen "nøgleforbrug" angiver formålet med nøglen i certifikatet. Eksempler på sådanne formål inkluderer kryptering, signaturer, certifikatsignering og så videre. Browsere afviser certifikater, der overtræder deres begrænsninger for nøglebrug, såsom at støde på et servercertifikat med en nøgle, der kun er beregnet til CRL-signering.
9. Browseren fortsætter med at behandle alle resterende kritiske udvidelser
Efter behandling af ovennævnte udvidelser fortsætter browsere med at validere alle resterende udvidelser, som det aktuelle certifikat udpeger som kritiske, inden de går videre til det næste. Hvis en browser når en stis bladcertifikat uden fejl, accepteres stien som gyldig. Hvis der opstår fejl, markeres stien som ugyldig, og der oprettes ikke en sikker forbindelse.
Konklusion
World Wide Web er et komplekst system af sammenkoblede og konstant udviklende bevægelige dele. Browsersikkerhed er således ikke et løst problem, og vi håber, at denne artikel har givet noget indblik i kompleksiteten af selv den ene komponent, vi har set på her. Tillid spiller en vigtig rolle for at holde dig sikker online, og derfor opfordrer vi dig til at forhøre dig mere om din CA's certifikatpolitik. (Du er velkommen til at gennemgå SSL.coms politikker her, faktisk.)
Tak for at du valgte SSL.com, hvor vi tror a sikrere Internettet er en bedre Internettet.
