Digitala signaturer, certifikat, och TLS

Föregående lektion lämnade en fråga öppen: asymmetrisk kryptering låter dig skicka en hemlighet till någon vars publika nyckel du har — men hur vet du att den publika nyckeln faktiskt tillhör dem, och inte en angripare däremellan? Digitala signaturer och certifikat besvarar det, och tillsammans gör de TLS, protokollet bakom varje https://-adress, möjligt.

Digitala signaturer: bevis på ursprung, inte hemlighet

En digital signatur kör asymmetrisk kryptering baklänges. Istället för att kryptera ett meddelande med någons publika nyckel så att bara de kan läsa det, signerar avsändaren ett meddelande med sin egen privata nyckel, och vem som helst kan verifiera det med avsändarens publika nyckel. Om verifieringen lyckas är två saker sanna: meddelandet kom från den som innehar den privata nyckeln, och det ändrades inte efteråt — samma kollisionsresistens-egenskap från föregående lektions diskussion om hashning gör manipulation upptäckbar. En signatur bevisar äkthet och integritet; den håller inte, i sig, meddelandet hemligt.

Certifikat: en signatur som går i god för en publik nyckel

Ett digitalt certifikat löser problemet ”vems publika nyckel är detta egentligen”. Som Cloudflares Learning Center förklarar är ett SSL/TLS-certifikat ”en datafil som finns på en webbplats ursprungsserver” och innehåller domännamnet, den publika nyckeln, ett utgångsdatum, och — avgörande — ”certifikatutfärdarens digitala signatur.” En certifikatutfärdare (CA) är en betrodd tredje part som kontrollerar att en webbplats kontrollerar domänen den begär ett certifikat för, och sedan signerar det certifikatet med sin egen privata nyckel. Din webbläsare levereras med en inbyggd lista över CA:er den litar på, så när den tar emot ett certifikat signerat av en av dem kan den lita på den publika nyckeln inuti utan att någonsin ha träffat webbplatsens operatör. Ett självsignerat certifikat — ett en webbplats signerar själv istället för att få från en CA — har ingen sådan extern bekräftelse, vilket är varför webbläsare som standard behandlar ett sådant som opålitligt.

TLS: att sätta båda i arbete

RFC 8446, specifikationen för TLS 1.3, beskriver en handskakning i faser: nyckelutbyte, där de två sidorna etablerar delat hemligt material; sedan autentisering, där, med RFC:ns egna ord, ”serversidan av kanalen autentiseras alltid; klientsidan autentiseras valfritt” — normalt bevisar bara webbplatsen sin identitet, inte besökaren. Servern bevisar vem den är med sitt certifikat och en signatur bara den kunde producera med sin privata nyckel. När båda sidor litar på anslutningen härleder de snabba symmetriska nycklar (föregående lektions AES, vanligtvis) för själva datan. RFC 8446 anger rakt ut vad detta ger dig: konfidentialitet och integritet för den utbytta datan, och autentisering av servern. Den anger också, lika tydligt, en gräns: ”TLS döljer inte längden på datan den överför”, och metadata som vilken server du anslöt till och när förblir synlig för alla som är positionerade att observera anslutningen.

Vad hänglåsikonen betyder och inte betyder

En nätfiskesajt byggd på en efterliknande domän kan ha ett fullt giltigt certifikat: TLS autentiserar domänen, inte avsikten hos den som registrerade den. Det är därför den tidigare lektionen om hur attacker utvecklas behandlar en falsk inloggningssida, hänglås och allt, som ett verkligt hot, inte en motsägelse.