Introduksjon
HTTPS (via SSL /TLS) bruker offentlig nøkkelkryptering for å beskytte nettleserkommunikasjonen mot å bli lest eller modifisert i transitt over Internett. Servere gir besøkende nettlesere med en offentlig nøkkel som brukes til å etablere en kryptert tilkobling for alle påfølgende datautvekslinger.
Imidlertid er det bare å motta en arbeid offentlig nøkkel alene garanterer ikke at den (og i forlengelse av serveren) faktisk eies av riktig fjernkontroll emne (dvs. person, selskap eller organisasjon). Man-in-the-middle angripere kan manipulere nettverk for å tjene sine egne nøkler, og dermed kompromittere all kommunikasjon.
Nettlesere forhindrer dette ved autentisering HTTPS-servere bruker sertifikater, som er digitale dokumenter som binde en offentlig nøkkel til et individuelt fag. Bindingen blir hevdet ved å ha en klarert Sertifiseringsinstans (CA) som SSL.com bekrefte identiteten til potensielle sertifikateiere, via automatiserte og manuelle kontroller mot kvalifiserte databaser.
Dette tillitsforholdet betyr at nettbrukernes sikkerhet ikke er absolutt; heller, det krever at brukerne stoler på nettlesere og CAer for å beskytte deres sikkerhet. Derfor tror vi det er i enhver brukers interesse å ha en grunnleggende forståelse av hvordan sertifikatvalidering fungerer.
Merk at sertifiseringsvalideringsprosessen (beskrevet i detalj i standarddokumentet RFC 5280) er ganske innblandet. I denne artikkelen vil vi prøve å gå deg langs en bane (en nettleser som validerer verts SSL /TLS sertifikat) og navigere forbi komplekse detaljer som er uten betydning for de fleste brukere.
Sertifikater og X.509-format
Sertifikater er digitale filer på alle måter, noe som betyr at de må følge et filformat for å lagre informasjon (f.eks. Signaturer, nøkler, utstedere, etc.). Mens privat PKI konfigurasjoner kan implementere hvilket som helst format for sertifikatene sine, offentlig klarert PKIs (dvs. de som er klarert av nettleserne) må samsvare med RFC 5280, som krever bruk av X.509 v3 format.
X.509 v3 lar sertifikater inkludere tilleggsdata, for eksempel bruksbegrensninger eller policyinformasjon, som utvidelser, med hver utvidelse enten kritisk or ukritisk. Nettlesere kan ignorere ugyldige eller ikke anerkjente ikke-kritiske utvidelser, men de er pålagt å behandle og validere alle kritiske utvidelser.
Sertifiseringsstier og behandlingsstier
CA bruker en privat nøkkel for å kryptografisk signere alle utstedte sertifikater. Slike signaturer kan ugjenkallelig bevise at et sertifikat ble utstedt av en spesifikk CA og at det ikke ble endret etter at det ble signert.
CAs etablerer eierskap til signeringsnøkkelen sin ved å ha et egenutstedt sertifikat (kalt root) for den tilsvarende offentlige nøkkelen. Luftfartsmyndighetene må følge nøye kontrollerte og reviderte prosedyrer for å opprette, administrere og bruke en rot, og for å minimere eksponeringen vil vanligvis bruke en rot til å utstede mellomliggende sertifikater. Disse mellomproduktene kan deretter brukes til å utstede sine kundersertifikater.
Nettlesere leveres med en innebygd liste over pålitelige røtter. (Dette er røtter fra CA-er som har bestått nettleserens strenge kriterier for inkludering.) For å verifisere et sertifikat, vil en nettleser få en sekvens av sertifikater, som hver har signert neste sertifikat i sekvensen, og kobler signaturens CA-rot til serverens sertifikat.
Denne sekvensen av sertifikater kalles a sertifiseringsvei. Stiens rot kalles a tillitsanker og serverens sertifikat kalles blad or slutt enhet sertifikat.
Banekonstruksjon
Ofte må nettlesere vurdere flere sertifiseringsveier til de kan finne en gyldig for et gitt sertifikat. Selv om en bane kan inneholde sertifikater som "sammenkobles" riktig til et kjent anker, kan selve banen avvises på grunn av begrensninger på banelengde, domenenavn, sertifikatbruk eller policy.
Å konstruere og evaluere alle mulige baner er en kostbar prosess utført for hvert nye sertifikat en nettleser møter. Nettlesere har implementert forskjellige optimaliseringer for å minimere antall avviste kandidatstier, men å fordype seg i slike detaljer er langt utenfor rammen for denne artikkelen.
Banevalidering
Etter at en kandidatsertifiseringsbane er konstruert, validerer nettlesere den ved hjelp av informasjonen i sertifikatene. En bane er gyldig hvis nettlesere kryptografisk kan bevise at startende fra et sertifikat direkte signert av et tillitsanker, ble hvert sertifikats tilsvarende private nøkkel brukt til å utstede den neste i banen, helt ned til bladsertifikatet.
Sertifiseringsvei valideringsalgoritme
RFC 5280 beskriver a standard algoritme som nettlesere følger for å validere en sertifiseringsbane for X.509-sertifikater.
I utgangspunktet går nettlesere gjennom alle sertifikater i banen som begynner med tillitsankeret (dvs. rotsertifikatet), og validerer hvert sertifikats grunnleggende informasjon og kritiske utvidelser.
Hvis prosedyren avsluttes med det siste sertifikatet i banen uten feil, godtas banen som gyldig. Hvis det produseres feil, er banen merket som ugyldig.
Grunnleggende sertifikatbehandling
Uavhengig av utvidelser, må nettlesere alltid bekrefte grunnleggende sertifikatinformasjon som signatur eller utsteder. Følgende seksjoner viser rekkefølgen av kontroller som nettlesere utfører.
1. Nettleseren bekrefter sertifikatets integritet
De signatur på sertifikatet kan verifiseres ved bruk av vanlig offentlig nøkkelkryptografi. Hvis signaturen er ugyldig, anses sertifikatet som endret etter utstedelsen og avvises derfor.
2. Nettleseren bekrefter sertifikatets gyldighet
Et sertifikat gyldighetsperiode er tidsintervallet som signerings-CA garanterer at det vil opprettholde informasjon om statusen. Nettlesere avviser alle sertifikater med en gyldighetsperiode som slutter før eller starter etter datoen og klokkeslettet for valideringskontrollen.
3. Nettleseren sjekker sertifikatets tilbakekallingsstatus
Når et sertifikat er utstedt, forventes det å være i bruk i hele gyldighetsperioden. Naturligvis kan forskjellige forhold føre til at et sertifikat blir ugyldig før det naturlig går ut.
Slike omstendigheter kan omfatte et emne som endrer navn eller mistenkt kompromiss med sin private nøkkel. I tilfeller som dette trenger en CA å tilbakekalle det tilsvarende sertifikatet, og brukere setter også sin lit til en CA for å varsle nettlesere om sertifikatens tilbakekallingsstatus.
RFC 5280 anbefaler at CAs bruker tilbakekallingslister for dette formålet.
Sertifikat tilbakekallingslister (CRL)
CAer utsteder jevnlig en signert, tidsstemplet liste over tilbakekalte sertifikater kalt a sertifikat tilbakekall liste (CRL). CRL-er distribueres i offentlig tilgjengelige arkiver, og nettlesere kan skaffe seg og konsultere CAs siste CRL når de validerer et sertifikat.
En feil ved denne metoden er at tidsgranulaturen for tilbakekalling er begrenset til CRL-utstedelsesperioden. En nettleser blir kun varslet om tilbakekall etter at alle nåværende utstedte CRL er planlagt å bli oppdatert. Avhengig av signerings-CAs policy, kan dette ta en time, dag eller til og med opptil en uke.
Online Certificate Status Protocol (OCSP)
Det er andre alternative metoder for å skaffe informasjon om tilbakekallingsstatus, hvor den mest populære er Online sertifikatstatus protokoll (OCSP).
Beskrevet i standarddokument RFC6960, OCSP lar en nettleser be om et spesifikt sertifikats tilbakekallingsstatus fra en online OCSP-server (også kalt a svare). Når den er riktig konfigurert, er OCSP mye mer umiddelbar og unngår problemet med CRL-oppdaterings-latency som er nevnt ovenfor. I tillegg, OCSP-stifting forbedrer ytelsen og hastigheten.
4. Nettleseren verifiserer utstederen
Sertifikater er normalt tilknyttet to enheter:
- De utsteder, som er enheten som eier signeringsnøkkelen og
- De emne, som viser til eieren av den offentlige nøkkelen som sertifikatet bekrefter.
Nettlesere sjekker at et sertifikat er utsteder feltet er det samme som emne feltet til det forrige sertifikatet i banen. For økt sikkerhet, de fleste PKI implementeringer bekrefter også at utstederens nøkkel er den samme som nøkkelen som signerte gjeldende sertifikat. (Merk at dette ikke gjelder for tillitsankeret, siden røttene er selvutstedt - dvs. at de har samme utsteder og emne.)
Behandling av begrensninger
X.509 v3-formatet lar en CA definere begrensninger eller begrensninger for hvordan hvert sertifikat blir validert og brukt som kritiske utvidelser. Hvert sertifikat i banen kan sette ekstra begrensninger som alle påfølgende sertifikater må overholde.
Sertifikatbegrensninger påvirker sjelden gjennomsnittlig Internett-bruker, selv om de er ganske vanlige i bedriftens SSL-løsninger. Funksjonelle begrensninger kan tjene flere operasjonelle formål, men deres viktigste bruk er å redusere kjente sikkerhetsproblemer.
5. Nettleseren kontrollerer navnebegrensninger
Et privateid (men offentlig pålitelig) mellomliggende CA med passende navnebegrensninger kan gi en organisasjon finkornet kontroll over sertifikatadministrasjon og utstedelse. Sertifikater kan begrenses til et bestemt domene eller domenetre (dvs. inkludert underdomener) for et selskap eller en organisasjons domenenavn. Navnebegrensninger brukes ofte til mellomliggende CA-sertifikater kjøpt fra en offentlig klarert CA for å forhindre at den mellomliggende CA utsteder helt gyldige sertifikater for tredjepartsdomener (f.eks. google.com).
6. Nettleseren sjekker policybegrensninger
En sertifikatpolicy er et juridisk dokument utgitt av en CA, som offisielt beskriver prosedyrene de følger for å utstede og administrere sertifikatene sine. CA kan utstede et sertifikat under en eller flere retningslinjer, og lenker til disse er inkludert i hvert sertifikat som er utstedt slik at pålitelige parter kan evaluere disse retningslinjene før de bestemmer seg for å stole på sertifikatet.
Av juridiske og operasjonelle årsaker kan sertifikater innføre begrensninger for hvilke policyer de kan være underlagt. Hvis det viser seg at et sertifikat inneholder kritiske policybegrensninger, må nettlesere validere dem før de fortsetter. (Imidlertid blir kritiske politiske begrensninger sjelden forekommende i den virkelige verden, og det vil bli sett bort fra resten av denne artikkelen.)
7. Nettleseren sjekker grunnleggende begrensninger (aka banen lengde)
X.509 v3-formatet lar utstedere definere den maksimale banelengden et sertifikat kan støtte. Dette gir kontroll over hvor langt hvert sertifikat kan plasseres i en sertifiseringsbane. Dette er faktisk viktig - nettlesere pleide å se bort fra sertifiseringsbanelengden til en forsker demonstrerte i 2009 presentasjon, hvordan han brukte nettsidens bladsertifikat til å smi et gyldig sertifikat for et stort e-handelsnettsted.
8. Nettleseren verifiser nøkkelbruk
Utvidelsen "nøkkelbruk" angir formålet med nøkkelen i sertifikatet. Eksempler på slike formål inkluderer kryptering, signaturer, sertifikatsignering og så videre. Nettlesere avviser sertifikater som bryter begrensningene for nøkkelbruk, for eksempel å møte et serversertifikat med en nøkkel kun ment for CRL-signering.
9. Nettleseren fortsetter å behandle alle gjenværende kritiske utvidelser
Etter å ha behandlet utvidelsene som er nevnt ovenfor, fortsetter nettleserne med å validere alle gjenværende utvidelser som gjeldende sertifikat betegner som kritiske, før de går videre til neste. Hvis en nettleser når en stis bladsertifikat uten feil, godtas stien som gyldig. Hvis det blir produsert feil, merkes banen som ugyldig, og det opprettes ikke en sikker forbindelse.
konklusjonen
World Wide Web er et komplekst system av sammenkoblede og stadig utviklende deler i bevegelse. Nettlesersikkerhet er dermed ikke et løst problem, og vi håper at denne artikkelen har gitt litt innsikt i kompleksiteten til og med den ene komponenten vi har sett på her. Tillit spiller en viktig rolle i å holde deg trygg på nettet, og av den grunn ber vi deg om å spørre mer om CAs sertifikatpolicy. (Gjennomgå gjerne SSL.coms retningslinjer her, faktisk.)
Takk for at du valgte SSL.com, der vi tror a sikrere Internett er et bedre Internett.
