Sertifikatmyndigheter er en av de viktigste hjørnesteinene for Internett-sikkerhet. En sertifikatmyndighet er noen som alle har tillit til i begynnelsen når ingen stoler på noen andre. Det er da denne sertifikatmyndighetens jobb (a.k.en CA) for å sikre at tillit opprettes mellom servere og klienter før de etablerer kommunikasjon over Internett.En CA er viktig ikke bare for HTTPS som brukes av nettlesere og nettapper, men også for krypterte e-postmeldinger, signerte programvareoppdateringer, VPN og mye mye mer. Vi tar det prototypiske eksemplet på HTTPS og lærer om CA, i denne spesielle sammenhengen. Selv om du kan ekstrapolere resultatet til andre programvarepakker.

Problemer med HTTP og vanlig tekst

Internett er en ikke-klarert kommunikasjonskanal. Når du sender eller mottar informasjon fra et gammelt HTTP-nettsted http: //www.eksempel.com i nettleseren din kan mange ting skje midt i pakkene dine.

1. En dårlig skuespiller kan fange opp kommunikasjonen, kopiere dataene for seg selv, før den sendes på nytt på kanalen mot deg eller serveren du snakket med. Uten noen av partenees kunnskap er informasjonen kompromittert. Vi må sørge for at kommunikasjonen er privat.
2. En dårlig skuespiller kan endre informasjonen når den sendes over kanalen. Bob kan ha sendt en melding “X” men Alice ville motta “Y” fra Bob, fordi en dårlig skuespiller snappet opp meldingen og endret den. Med andre ord, integritet av meldingen er kompromittert.
3. Til slutt, og viktigst, må vi sørge for at personen vi snakker med, virkelig er den de sier de er. Går tilbake til eksempel.com domene. Hvordan kan vi forsikre oss om at serveren som svarte oss er den rettmessige innehaveren av www.eksempel.com? Når som helst i nettverket ditt, kan du bli dirigert til en annen server. En DNS et sted er ansvarlig for å konvertere et domenenavn, for eksempel www.eksempel.com, til en IP-adresse på det offentlige internett. Men nettleseren din har ingen måte å verifisere at den DNS-oversatte IP-adressen.

De to første problemene kan løses ved å kryptere meldingen før den sendes over Internett til serveren. Det vil si ved å bytte til HTTPS. Imidlertid er det siste problemet, problemet med identitet hvor en sertifikatmyndighet spiller inn.

Starter krypterte HTTP-økter

Hovedproblemet med kryptert kommunikasjon over en usikker kanal er “Hvordan starter vi det?”

Det aller første trinnet vil involvere de to partene, nettleseren din og serveren, til å utveksle krypteringsnøklene som skal utveksles over den usikre kanalen. Hvis du ikke er kjent med begrepet nøkler, kan du tenke på dem som et veldig langt tilfeldig generert passord som dataene dine blir kryptert med før de sendes over den usikre kanalen.

Hvis nøklene blir sendt over en usikker kanal, kan hvem som helst høre på det og kompromittere sikkerheten til HTTPS-økten din i fremtiden. Dessuten, hvordan kan vi stole på at nøkkelen blir sendt av en server som hevder å være www.eksempel.com er faktisk den faktiske eieren av det domenenavnet? Vi kan ha en kryptert kommunikasjon med en ondsinnet part som maskerer seg som et legitimt nettsted og ikke vet forskjellen.

Så problemet med å sikre identitet er viktig hvis vi ønsker å sikre sikker nøkkelutveksling.

Sertifikatmyndigheter

Du har kanskje hørt om LetsEncrypt, DigiCert, Comodo og noen få andre tjenester som tilbyr TLS-sertifikater for domenenavnet ditt. Du kan velge den som passer ditt behov. Nå må personen / organisasjonen som eier domenet bevise på en eller annen måte overfor sertifikatmyndigheten at de faktisk har kontroll over domenet. Dette kan gjøres ved å enten opprette en DNS-post med en unik verdi, slik sertifikatmyndigheten ber om, eller du kan legge til en fil på webserveren din, med innhold spesifisert av sertifikatmyndigheten. CA kan da lese denne filen og bekreft at du er gyldig eier av domenet.

Deretter forhandler du om et TLS-sertifikat med CA, og det resulterer i en privat nøkkel og et offentlig TLS-sertifikat utstedt til domenet ditt. Meldinger kryptert av din private nøkkel kan deretter dekrypteres av det offentlige sertifikatet og omvendt. Dette er kjent som asymmetrisk kryptering

Klientleserne, som Firefox og Chrome (noen ganger til og med operativsystemet), har kunnskap fra sertifikatmyndigheter. Denne informasjonen blir bakt i nettleseren / enheten helt fra begynnelsen (det vil si når de er installert) slik at de vet at de kan stole på visse CAer. Nå, når de prøver å koble til www.eksempel.com over HTTPS og se et sertifikat utstedt av, si DigiCert, kan nettleseren faktisk verifisere at ved hjelp av nøklene som er lagret lokalt. Egentlig er det noen flere mellomsteg til det, men dette er en god forenklet oversikt over hva som skjer.

Nå som sertifikatet gitt av www.eksempel.com kan stole på, dette brukes til å forhandle om en unik symmetrisk krypteringsnøkkel som brukes mellom klienten og serveren for resten av økten sin. I symmetrisk kryptering brukes en nøkkel til å kryptere så vel som dekryptering, og er vanligvis mye raskere enn dets asymmetriske motstykke.

Nyanser

Hvis ideen om TLS og Internett-sikkerhet appellerer til deg, kan du se nærmere på dette emnet ved å grave i LetsEncrypt og deres gratis TLS CA. Det er mye mer detaljert i hele denne rigmarolen enn angitt ovenfor.

Andre ressurser som jeg kan anbefale for å lære mer om TLS er Troy Hunts blogg og arbeid utført av EFF som HTTPS Everywhere og Certbot. Alle ressursene er gratis tilgjengelig og veldig billige å implementere (du må bare betale for domeneregistrering og VPS timegebyr) og få en praktisk opplevelse.