Digitale signaturer, sertifikater, og TLS

Forrige leksjon lot ett spørsmål stå åpent: asymmetrisk kryptering lar deg sende en hemmelighet til noen hvis offentlige nøkkel du har — men hvordan vet du at den offentlige nøkkelen faktisk tilhører dem, og ikke en angriper i mellom? Digitale signaturer og sertifikater svarer på det, og sammen gjør de TLS, protokollen bak hver https://-adresse, mulig.

Digitale signaturer: bevis på opphav, ikke hemmelighold

En digital signatur kjører asymmetrisk kryptering baklengs. I stedet for å kryptere en melding med noens offentlige nøkkel slik at bare de kan lese den, signerer avsenderen en melding med sin egen private nøkkel, og hvem som helst kan verifisere den med avsenderens offentlige nøkkel. Hvis verifiseringen lykkes, er to ting sanne: meldingen kom fra den som har den private nøkkelen, og den ble ikke endret etterpå — den samme kollisjonsmotstand-egenskapen fra forrige leksjons diskusjon om hashing er det som gjør tukling oppdagbart. En signatur beviser autentisitet og integritet; den holder ikke, alene, meldingen hemmelig.

Sertifikater: en signatur som går god for en offentlig nøkkel

Et digitalt sertifikat løser problemet «hvem sin offentlige nøkkel er dette egentlig». Som Cloudflares Learning Center forklarer, er et SSL/TLS-sertifikat «en datafil som ligger på et nettsteds opprinnelsesserver» og inneholder domenenavnet, den offentlige nøkkelen, en utløpsdato, og — avgjørende — «sertifikatmyndighetens digitale signatur.» En sertifikatmyndighet (CA) er en pålitelig tredjepart som sjekker at et nettsted kontrollerer domenet det ber om et sertifikat for, og deretter signerer det sertifikatet med sin egen private nøkkel. Nettleseren din leveres med en innebygd liste over CA-er den stoler på, så når den mottar et sertifikat signert av en av dem, kan den stole på den offentlige nøkkelen inni uten noensinne å ha møtt nettstedets operatør. Et selvsignert sertifikat — ett et nettsted signerer selv i stedet for å få fra en CA — har ingen slik ekstern bekreftelse, som er hvorfor nettlesere som standard behandler ett som upålitelig.

TLS: å sette begge deler i arbeid

RFC 8446, spesifikasjonen for TLS 1.3, beskriver et håndtrykk i faser: nøkkelutveksling, der de to sidene etablerer delt hemmelig materiale; deretter autentisering, der, i RFC-ens ord, «serversiden av kanalen er alltid autentisert; klientsiden er valgfritt autentisert» — normalt beviser bare nettstedet sin identitet, ikke besøkeren. Serveren beviser hvem den er ved hjelp av sitt sertifikat og en signatur bare den kunne produsere med sin private nøkkel. Når begge sider stoler på tilkoblingen, utleder de raske symmetriske nøkler (forrige leksjons AES, typisk) for de faktiske dataene. RFC 8446 sier rett ut hva dette gir deg: konfidensialitet og integritet for dataene som utveksles, og autentisering av serveren. Den sier også, like tydelig, en grense: «TLS skjuler ikke lengden på dataene den overfører», og metadata som hvilken server du koblet til og når forblir synlig for alle som er posisjonert til å observere tilkoblingen.

Hva hengelåsikonet betyr og ikke betyr

Et phishing-nettsted bygget på et lignende domene kan ha et helt gyldig sertifikat: TLS autentiserer domenet, ikke intensjonen til den som registrerte det. Dette er hvorfor den tidligere leksjonen om hvordan angrep utfolder seg behandler en falsk innloggingsside, hengelås og alt, som en reell trussel, ikke en motsigelse.