Sertifikatmyndigheter er en av de viktigste hjørnesteinene for internettsikkerhet. En sertifikatmyndighet er noen som er klarert av alle, i begynnelsen, når ingen stoler på noen andre. Det er da jobben til denne sertifikatmyndigheten (a.k.a ca) for å sikre at tillit er etablert mellom servere og klienter før de etablerer kommunikasjon over internett.En CA er viktig ikke bare for https som brukes av nettlesere og webapper, men også for krypterte e -postmeldinger, signerte programvareoppdateringer, VPN -er og mye mye mer. Vi vil ta det prototypiske eksemplet på HTTPS og lære om CA, i denne spesielle sammenhengen. Selv om du kan ekstrapolere resultatet til en hvilken som helst annen programvaresuite.

Problemer med HTTP og ren tekst

Internett er en ikke -tillitskanal for kommunikasjon. Når du sender eller mottar informasjon fra et gammelt HTTP -nettsted http: //www.eksempel.com I nettleseren din kan mange ting skje midtveis til pakkene dine.

1. En dårlig skuespiller kan avskjære kommunikasjonen, kopiere dataene for seg selv, før de setter den ut igjen på kanalen mot deg eller serveren du snakket med. Uten kunnskap fra noen av partene blir informasjonen kompromittert. Vi må sikre at kommunikasjonen er privat.
2. En dårlig skuespiller kan endre informasjonen når den blir sendt over kanalen. Bob kan ha sendt en melding “X” Men Alice ville motta “Y” fra Bob, fordi en dårlig skuespiller avskjærte meldingen, og endret den. Med andre ord, integritet av meldingen er kompromittert.
3. Til slutt, og viktigst av alt, må vi sikre at personen vi snakker med faktisk er den de sier at de er. Går tilbake til eksempel.com domene. Hvordan kan vi sørge for at serveren som svarte tilbake til oss faktisk er den rettmessige innehaveren av www.eksempel.com? Når som helst i nettverket ditt, kan du bli feildirigert til en annen server. En DNS et sted er ansvarlig for å konvertere et domenenavn, for eksempel www.eksempel.com, inn i en IP -adresse på det offentlige internett. Men nettleseren din har ingen måte å bekrefte at 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, identitetsproblemet der en sertifikatmyndighet spiller inn.

Initierer 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, for å utveksle krypteringstastene som skal byttes over den usikre kanalen. Hvis du ikke er kjent med begrepet nøkler, kan du tenke på dem som et virkelig langt tilfeldig generert passord som dataene dine vil bli kryptert før du blir sendt over den usikre kanalen.

Vel, hvis nøklene blir sendt over en usikker kanal, kan hvem som helst lytte til det og kompromittere sikkerheten til din HTTPS -økt i fremtiden. 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 et ondsinnet parti som er maskert 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 ditt domenenavn. Du kan velge den som passer ditt behov. Nå må personen/organisasjonen som eier domenet bevise på en eller annen måte til sertifikatmyndigheten at de faktisk har kontroll over domenet. Dette kan gjøres ved enten og bekreft at du er den gyldige eieren av domenet.

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

Klientens nettlesere, som Firefox og Chrome (noen ganger til og med operativsystemet) har kunnskap om 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 CAS. Nå, når de prøver å koble seg til www.eksempel.com over https og se et sertifikat utstedt av, si digiCert, nettleseren faktisk kan bekrefte at ved bruk av nøklene som er lagret lokalt. Egentlig er det noen flere mellomtrinn til det, men dette er en god forenklet oversikt over hva som skjer.

Nå som sertifikatet levert av www.eksempel.com kan stole på, dette brukes til å forhandle om en unik symmetrisk krypteringsnøkkel som brukes mellom klienten og serveren for den gjenværende av sesjonen deres. I symmetrisk kryptering brukes en nøkkel til å kryptere så vel som dekryptering og er vanligvis mye raskere enn dens asymmetriske motpart.

Nyanser

Hvis ideen om TLS og Internett -sikkerhetsappellerer til deg, kan du se nærmere på dette emnet ved å grave i Letsencrypt og deres gratis TLS CA. Det er mye mer minutiat for hele Rigmarole enn nevnt 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 overalt og certbot. Alle ressursene er gratis å få tilgang.