Er en hengelås til å stole på?
Vi har alle lært oss å påse at forbindelsene vi bruker til tjenester på Internett er sikre; “Sjekk at du har en hengelås i adressefeltet”. Hvilken sikkerhet dette gir oss og hvor skjørt dette laget av sikkerhet er, har vi mindre forhold til.
Denne teksten beskriver litt om hvordan det hele henger sammen og forsøker å formidle hva vi egentlig velger å stole på når vi bruker tjenester på Internett. Formålet er ikke å skremme, men å skape litt bevissthet rundt de svake sidene av denne sikkerheten og hvordan vi kan forbedre den med relativt enkle midler.
Hele grunnlaget for SSL/TLS (begrepene brukes om hverandre) er sertifikatene som brukes på server siden. Disse hadde opprinnelig to formål:
- Bevise at serveren er den som den utgir seg for å være ved at den har et sertifikat signert av en tredjepart vi har valgt å stole på.
- Nøkkelparet i sertifikatet ble brukt til å etablere den krypterte kanalen mellom server og klient.
Punkt 2 er i dag lite brukt, da krypteringen i dag i stor grad etableres med nøkkel-par generert til dette formål for hver forbindelse. Dermed er signering av server-identitet den vesentlige funksjonen sertifikatet har, og det er dette område denne teksten vil belyse.
Sertifikatene som benyttes i forbindelse med tilkobling til en server med https-protokollen, former en kjede fra sertifikatet som inneholder serverens identitet til et rot sertifikat vi stoler på. Imellom disse ligger det normalt ett eller flere sertifikat, gjerne kalt chain, issuing eller intermediate sertifikat. Typisk mottar vi hele kjeden fra serveren ved tilkobling, med unntak av rot sertifikatet. Dette er lagret i vår egen enhet og representerer da en instans vi stoler på.
Men hvor mange av oss har et bevisst forhold til den tilliten vi gir en tilfeldig server vi kobles til? Er det et valg vi selv har gjort å stole på eksempelvis Comodo, GoDaddy, Let’s Encrypt eller vår norske root CA (Certificate Authority), Buypass? Med mindre man er langt over gjennomsnittlig interessert i temaet, er nok svaret på det spørsmålet et klart “Nei”. Så kan det naturligvis hende at vi i jobbsammenheng får hjelp av en serviceinnstilt IT-avdeling som gjør disse valgene på vegne av organisasjonen. For de aller fleste er det Microsoft som har bestemt hvem vi skal stole på. Produkter fra andre enn Microsoft bruker oftest en root CA-liste, ccadb (Common CA DataBase). Den er i stor grad lik Microsoft sin.
Og her er vi ved kjernen av budskapet. Disse listene som inneholder root CA’er vi stoler på dekker hele verden. Dermed velger noen, på våre vegne, å stole på CAer som har tilhold i land som har et annet forhold til personvern, pressefrihet og rett til et privatliv enn vi er vant med her hjemme. Blant annet inneholder listene et knippe kinesiske CAer, samt et par Tyrkiske. Noen CAer er tekstet med “Government” og det er dermed ikke utenkelig at politiske endringer i et land kan sette integriteten til CAen under press.
Hensikten er å påpeke hvordan denne kjeden av tillit bygges uten at vi har et bevisst, selvvalgt forhold til det. Her et par, forhåpentligvis konstruerte, scenario som demonstrerer hva som er mulig i kombinasjon med rotCA-listen de fleste av oss stoler på:
- Sverige har siden 2008 FRA-loven som gir enkelte svenske institusjoner lov til å overvåke all datatrafikk som går gjennom Sverige. Mye av den norske trafikken går den veien. I Microsoft sin CA-liste ligger en root CA kalt “Swedish Government Root Authority v3”. I praksis betyr dette at trafikk fra Norge lovlig kan avlyttes, og dersom noen kombinerer det aktuelle root CA sertifikatet med en passende proxy-løsning som utsteder sertifikat “on the fly”, vil ikke brukeren merke at trafikken faktisk kan dekrypteres og leses i klartekst (i teorien også endres) før den krypteres på ny og sendes videre til den aktuelle tjenesten som om ingenting har skjedd.
- Det har skjedd ved et par anledninger at mye av Internett-trafikken har blitt rutet om Kina ved et uhell (velger her å ikke bruke anførselstegn rundt uhell). Når min PC inneholder root CAer som potensielt kontrolleres av kinesiske myndigheter er det mulig ikke bare å se trafikken flyte forbi, men også aktivt dekryptere og rekryptere uten at det er lett for meg å se hva som foregår.
Igjen, dette er konstruerte eksempler som har til hensikt å vise hva en teknisk sett kan gjøre, uten at brukeren har mulighet til å oppdage det.
I praksis distribuerer Microsoft listen over CAer som inngår i “Microsoft Trusted Root Program” via Windows Update. Det fungerer slik at når en Windows-maskin mottar et sertifikat fra en server og dette er signert av en CA som maskinen ikke har lagret som “trusted”, vil maskinen kontakte Windows Update og spørre om det finnes et gyldig rot sertifikat for den aktuelle sertifikatkjeden.
Totalt er det ca. 400 trustede rotCAer i listene nevnt over. Det kan nok være en god idé å ha et bevisst forhold til denne listen, spesielt dersom man behandler konfidensiell informasjon som kan være av interesse for organisasjoner som kan tenkes å ha påvirkning på eiere av noen av root CAene vi stoler på.
I Active Directory kan en med GPO redigere listen, og dersom en har proxy-servere for utgående trafikk til internett i organisasjonen, kan man som regel editere listene der slik at en har kontroll på vegne av alle maskiner i lokalnettet.
Vi er av den oppfatning at mange har en jobb å gjøre på dette området.
Referanser:
CCADB:https://wiki.mozilla.org/CA/Included_Certificates
Microsoft: https://docs.microsoft.com/en-us/security/trusted-root/participants-list
BGP Routing hendelse: https://arstechnica.com/information-technology/2019/06/bgp-mishap-sends-european-mobile-traffic-through-china-telecom-for-2-hours/