Robert Heaton

HTTPS er ganske enkelt din standard-HTTP-protokol, som er overhældt med et generøst lag af lækker SSL/TLS-kryptering. Medmindre noget går grueligt galt (og det kan det), forhindrer det folk som den berygtede Eve i at se eller ændre de forespørgsler, der udgør din browsingoplevelse; det er det, der holder dine adgangskoder, kommunikations- og kreditkortoplysninger sikre på kablet mellem din computer og de servere, du ønsker at sende disse data til. Selv om den lille grønne hængelås og bogstaverne “https” i din adresselinje ikke betyder, at der ikke stadig er rigeligt med reb til både dig og det websted, du besøger, til at hænge dig selv et andet sted, hjælper de dig i det mindste med at kommunikere sikkert, mens du gør det.

Hvad er HTTPS, og hvad gør det?

HTTPS tager den velkendte og forståede HTTP-protokol og lægger simpelthen et SSL/TLS-krypteringslag (herefter blot benævnt “SSL”) oven på den. Servere og klienter taler stadig præcis det samme HTTP til hinanden, men over en sikker SSL-forbindelse, der krypterer og dekrypterer deres anmodninger og svar. SSL-laget har to hovedformål:

• Sikring af, at du taler direkte til den server, som du tror, du taler til
• Sikring af, at kun serveren kan læse det, du sender den, og kun du kan læse det, den sender tilbage

Den virkelig, virkelig smarte del er, at enhver kan opsnappe hver eneste af de meddelelser, du udveksler med en server, herunder dem, hvor I aftaler, hvilken nøgle og krypteringsstrategi I skal bruge, og stadig ikke være i stand til at læse nogen af de faktiske data, du sender.

Sådan oprettes en SSL-forbindelse

En SSL-forbindelse mellem en klient og en server oprettes ved hjælp af en handshake, hvis mål er følgende:

• For at overbevise klienten om, at den taler med den rigtige server (og eventuelt visa versa)
• For at parterne er blevet enige om en “cipher suite”, som omfatter, hvilken krypteringsalgoritme de vil bruge til at udveksle data
• For at parterne er blevet enige om eventuelle nødvendige nøgler til denne algoritme

Når forbindelsen er etableret, kan begge parter bruge den aftalte algoritme og de aftalte nøgler til at sende meddelelser sikkert til hinanden. Vi vil dele håndslaget op i 3 hovedfaser – Hello, Certificate Exchange og Key Exchange.

1. Hello – Håndslaget begynder med, at klienten sender en ClientHello besked. Denne indeholder alle de oplysninger, som serveren har brug for for at kunne oprette forbindelse til klienten via SSL, herunder de forskellige cipher suites og den maksimale SSL-version, som den understøtter. Serveren svarer med en ServerHello, som indeholder lignende oplysninger, som klienten har brug for, herunder en beslutning baseret på klientens præferencer om, hvilken cipher suite og version af SSL der skal anvendes.

2. Certificate Exchange – Nu hvor kontakten er blevet etableret, skal serveren bevise sin identitet over for klienten. Dette gøres ved hjælp af dens SSL-certifikat, som er en meget lille smule ligesom dens pas. Et SSL-certifikat indeholder forskellige data, herunder navnet på ejeren, den ejendom (f.eks. domæne), det er knyttet til, certifikatets offentlige nøgle, den digitale signatur og oplysninger om certifikatets gyldighedsdatoer. Klienten kontrollerer, at den enten implicit stoler på certifikatet, eller at det er verificeret og betroet af en af flere certifikatudstedende myndigheder (CA’er), som den også implicit stoler på. Meget mere om dette om kort tid. Bemærk, at serveren også har lov til at kræve et certifikat for at bevise klientens identitet, men dette sker typisk kun i meget følsomme applikationer.

3. Nøgleudveksling – Krypteringen af de faktiske meddelelsesdata, der udveksles af klienten og serveren, vil ske ved hjælp af en symmetrisk algoritme, hvis nøjagtige karakter allerede blev aftalt i Hello-fasen. En symmetrisk algoritme anvender en enkelt nøgle til både kryptering og dekryptering, i modsætning til asymmetriske algoritmer, der kræver et offentligt/privat nøglepar. Begge parter skal blive enige om denne enkelte, symmetriske nøgle, en proces, der udføres sikkert ved hjælp af asymmetrisk kryptering og serverens offentlige/private nøgler.

Klienten genererer en tilfældig nøgle, der skal bruges til den vigtigste, symmetriske algoritme. Den krypterer den ved hjælp af en algoritme, der også blev aftalt i Hello-fasen, og serverens offentlige nøgle (som findes på serverens SSL-certifikat). Den sender denne krypterede nøgle til serveren, hvor den dekrypteres ved hjælp af serverens private nøgle, og de interessante dele af håndtrykket er afsluttet. Parterne er tilstrækkeligt tilfredse med, at de taler med den rigtige person, og de er i hemmelighed blevet enige om en nøgle til symmetrisk kryptering af de data, som de skal sende hinanden. HTTP-forespørgsler og -svar kan nu sendes ved at danne en meddelelse i klartekst og derefter kryptere og sende den. Den anden part er den eneste, der ved, hvordan denne besked kan dekrypteres, og derfor kan Man In The Middle-angribere ikke læse eller ændre de anmodninger, de måtte opsnappe.

Certifikater

På det mest grundlæggende niveau er et SSL-certifikat blot en tekstfil, og alle med en teksteditor kan oprette et. Du kan faktisk helt banalt oprette et certifikat, der hævder, at du er Google Inc. og at du kontrollerer domænet gmail.com. Hvis dette var hele historien, ville SSL være en joke; identitetsbekræftelse ville i bund og grund bestå i, at klienten spørger serveren “Er du Google?”, serveren svarer “Ja, helt sikkert, her er et stykke papir med “Jeg er Google” skrevet på”, og klienten siger “Okay, fint, her er alle mine data”. Den magi, der forhindrer denne farce, ligger i den digitale signatur, som gør det muligt for en part at verificere, at en anden parts stykke papir virkelig er lovligt.

Der er 2 fornuftige grunde til, at man kan stole på et certifikat:

• Hvis det er på en liste over certifikater, som man implicit stoler på
• Hvis det kan bevise, at det er betroet af kontrollanten af et af certifikaterne på ovennævnte liste

Det første kriterium er let at kontrollere. Din browser har en forudinstalleret liste over betroede SSL-certifikater fra certifikatudstedere (CA’er), som du kan se, tilføje og fjerne fra. Disse certifikater kontrolleres af en centraliseret gruppe af (i teorien, og generelt i praksis) ekstremt sikre, pålidelige og troværdige organisationer som Symantec, Comodo og GoDaddy. Hvis en server fremviser et certifikat fra denne liste, så ved du, at du kan stole på dem.

Det andet kriterium er meget vanskeligere. Det er let for en server at sige “øh ja, mit navn er øh, Microsoft, du stoler på Symantec, og øh, de stoler helt på mig, så det hele er i orden”. En lidt klog klient kan så gå hen og spørge Symantec: “Jeg har en Microsoft her, som siger, at du stoler på dem, er det sandt?” Men selv hvis Symantec siger “ja, vi kender dem, Microsoft er lovlige”, så ved du stadig ikke, om den server, der hævder at være Microsoft, rent faktisk er Microsoft eller noget meget værre. Det er her, digitale signaturer kommer ind i billedet.

3.2 Digitale signaturer

Som allerede nævnt har SSL-certifikater et tilknyttet offentligt/privat nøglepar. Den offentlige nøgle distribueres som en del af certifikatet, og den private nøgle opbevares utroligt sikkert. Dette par asymmetriske nøgler bruges i SSL-håndslaget til at udveksle en yderligere nøgle for begge parter til at kryptere og dekryptere data symmetrisk. Klienten bruger serverens offentlige nøgle til at kryptere den symmetriske nøgle og sende den sikkert til serveren, og serveren bruger sin private nøgle til at dekryptere den. Alle kan kryptere ved hjælp af den offentlige nøgle, men kun serveren kan dekryptere ved hjælp af den private nøgle.

Det modsatte er tilfældet for en digital signatur. Et certifikat kan “signeres” af en anden myndighed, hvorved myndigheden i realiteten siger: “Vi har verificeret, at den ansvarlige for dette certifikat også kontrollerer den ejendom (domæne), der er anført på certifikatet”. I dette tilfælde bruger myndigheden sin private nøgle til at (groft sagt) at kryptere indholdet af certifikatet, og denne krypterede tekst vedhæftes certifikatet som dets digitale signatur. Enhver kan dekryptere denne signatur ved hjælp af myndighedens offentlige nøgle og verificere, at den resulterer i den forventede dekrypterede værdi. Men kun autoriteten kan kryptere indholdet ved hjælp af den private nøgle, og derfor er det kun autoriteten, der overhovedet kan oprette en gyldig signatur.

Så hvis en server kommer forbi og hævder at have et certifikat for Microsoft.com, der er underskrevet af Symantec (eller en anden CA), behøver din browser ikke at tage den på ordet. Hvis det er lovligt, vil Symantec have brugt deres (ultrahemmelige) private nøgle til at generere serverens SSL-certifikatets digitale signatur, og din browser kan derfor bruge deres (ultraoffentlige) offentlige nøgle til at kontrollere, at denne signatur er gyldig. Symantec vil have taget skridt til at sikre, at den organisation, som de underskriver for, virkelig ejer Microsoft.com, og da din klient stoler på Symantec, kan den således være sikker på, at den virkelig taler med Microsoft Inc.

3.3 Selv-signering

Bemærk, at alle rod-CA-certifikater er “selv-signerede”, hvilket betyder, at den digitale signatur genereres ved hjælp af certifikatets egen private nøgle. Der er ikke noget i sig selv specielt ved et root CA-certifikat – du kan generere dit eget selvsignerede certifikat og bruge det til at signere andre certifikater, hvis du ønsker det. Men da dit tilfældige certifikat ikke er forudindlæst som en CA i nogen browsere nogen steder, vil ingen af dem stole på dig til at underskrive hverken dine egne eller andre certifikater. Du siger i realiteten “øh ja, jeg er helt Microsoft, her er et officielt identitetscertifikat udstedt og underskrevet af mig selv”, og alle velfungerende browsere vil få en meget skræmmende fejlmeddelelse som svar på dine tvivlsomme legitimationsoplysninger.

Dette lægger en enorm byrde på alle udgivere af browsere og operativsystemer for kun at stole på rene rod-CA’er, da det er disse organisationer, som deres brugere ender med at stole på, når de gennemgår websteder og holder certifikater sikre. Dette er ikke nogen nem opgave.

3.4 Hvad stoler du på?

Det er interessant at bemærke, at din klient teknisk set ikke forsøger at verificere, om den skal stole på den part, der har sendt den et certifikat, men om den skal stole på den offentlige nøgle, der er indeholdt i certifikatet. SSL-certifikater er helt åbne og offentlige, så enhver angriber kan få fat i Microsofts certifikat, opsnappe en klients anmodning til Microsoft.com og præsentere det legitime certifikat for den. Klienten ville acceptere dette og med glæde begynde håndslaget. Men når klienten krypterer den nøgle, der skal bruges til selve datakrypteringen, vil den gøre det ved hjælp af den rigtige Microsofts offentlige nøgle fra dette rigtige certifikat. Da angriberen ikke har Microsofts private nøgle til at dekryptere den, er han nu fanget. Selv om håndslaget er afsluttet, vil de stadig ikke kunne dekryptere nøglen, og de vil derfor ikke kunne dekryptere nogen af de data, som klienten sender til dem. Orden opretholdes, så længe angriberen ikke har kontrol over et betroet certifikats private nøgle. Hvis klienten på en eller anden måde bliver lokket til at stole på et certifikat og en offentlig nøgle, hvis private nøgle kontrolleres af en angriber, begynder problemerne.

4.1 Kan en kaffebar overvåge min HTTPS-trafik over deres netværk?

Nej. Magien ved kryptografi med offentlige nøgler betyder, at en angriber kan se hver eneste byte af data, der udveksles mellem din klient og serveren, og stadig ikke aner, hvad I siger til hinanden ud over nogenlunde, hvor mange data I udveksler. Din normale HTTP-trafik er dog stadigvæk meget sårbar på et usikkert wi-fi-netværk, og et ustabilt websted kan blive offer for et hvilket som helst antal omgåelser, der på en eller anden måde narrer dig til at sende HTTPS-trafik enten over almindelig HTTP eller bare til det helt forkerte sted. Selv om en login-formular f.eks. sender en kombination af brugernavn og adgangskode over HTTPS, kan en angriber, hvis selve formularen indlæses usikkert over HTTP, opsnappe formularens HTML på vej til din maskine og ændre den til at sende loginoplysningerne til sit eget slutpunkt.

4.2 Kan min virksomhed overvåge min HTTPS-trafik over deres netværk?

Hvis du også bruger en maskine, der kontrolleres af din virksomhed, så ja. Husk, at der ved roden af enhver tillidskæde ligger en implicit betroet CA, og at der er gemt en liste over disse myndigheder i din browser. Din virksomhed kan bruge deres adgang til din maskine til at tilføje deres eget selvsignerede certifikat til denne liste over CA’er. De kan så opsnappe alle dine HTTPS-forespørgsler og præsentere certifikater, der hævder at repræsentere det pågældende websted, og som er underskrevet af deres falske CA og derfor uden tvivl er troværdige for din browser. Da du krypterer alle dine HTTPS-forespørgsler ved hjælp af deres falske certifikats offentlige nøgle, kan de bruge den tilsvarende private nøgle til at dekryptere og inspicere (og endda ændre) din forespørgsel og derefter sende den videre til det sted, den skal sendes. Det gør de sandsynligvis ikke. Men det kunne de.

Helt tilfældigt er det også sådan, man bruger en proxy til at inspicere og ændre de ellers utilgængelige HTTPS-forespørgsler fra en iPhone-app.

4.3 Hvad skete der så med Lavabit og FBI?

Lavabit var Edward Snowdens supersikre e-mail-udbyder under NSA-lækagerne vanviddet i 2013. Som vi har set, kunne intet standardhackeri give FBI mulighed for at se alle data på vej mellem Lavabit og dets kunder. Uden den private nøgle til Lavabits SSL-certifikat var agenturet på røven. En hjælpsom amerikansk dommer fortalte imidlertid Lavabit-stifteren Ladar Levison, at han var nødt til at udlevere denne nøgle, hvilket reelt gav FBI frie hænder til at snage i trafikken efter behag. Levison gjorde et tappert forsøg på at trække tiden ud ved at udlevere den 2 560 tegn store nøgle på 11 sider i papirudgave med 4 punkts skrift, men han fik en kendelse, der krævede, at han skulle udlevere nøglen i et brugbart format, ellers skulle han betale en bøde på 5 000 USD pr. dag, indtil han gjorde det.

Når han havde efterkommet dette, tilbagekaldte GoDaddy, Lavabits CA, certifikatet, da han (korrekt) havde vurderet, at det var kompromitteret. Dette tilføjede Lavabit-certifikatet til en Certificate Revocation List (CRL), en liste over miskrediterede certifikater, som kunderne ikke længere bør stole på, når de skal levere en sikker forbindelse. Kompromitterede, selvsignerede eller på anden måde utroværdige certifikater medfører, at browsere viser en stor rød fejlmeddelelse og enten fraråder eller direkte forbyder brugeren at foretage sig yderligere handlinger. Desværre vil browsere fortsat stole på et ødelagt certifikat, indtil de trækker de nyeste opdateringer til CRL’en, en proces, som tilsyneladende er ufuldkommen i praksis.

Slutning

HTTPS er ikke ubrydelig, og SSL-protokollen skal hele tiden udvikles, efterhånden som nye angreb mod den opdages og nedkæmpes. Men det er stadig en imponerende robust måde at overføre hemmelige data på uden at bekymre sig om, hvem der kan se dine beskeder. Der er naturligvis mange implementeringsdetaljer, som ikke er nævnt her, f.eks. det nøjagtige format og rækkefølgen af handshake-beskederne, forkortede handshakes for at hente de seneste sessioner uden at skulle genforhandle nøgler og cipher suites, og de mange forskellige krypteringsmuligheder, der er tilgængelige på hvert trin. Det vigtigste at huske er, at selv om HTTPS sikrer dataene på vej til deres bestemmelsessted, beskytter det dig (som bruger eller udvikler) på ingen måde mod XSS, databaselækager eller andre ting, der kan ske i løbet af natten. Vær glad for, at den har din ryg, men vær på vagt. Med Will Smiths udødelige ord: “Walk in shadow, move in silence, guard against extra-terrestrial violence.”

Hvis du nød dette, vil du sikkert også nyde mit indlæg, der forklarer detaljerne i 2015’s FREAK-sårbarhed i SSL.