NTNU-studenter fikk utfordrende oppgave fra Buypass: Lagde sertifikatloggmonitor fra bunnen av

Samtidig som at stadig flere nettsteder leveres over krypterte HTTPS-forbindelser, har det skjedd mye innen økosystemet for de digitale sikkerhetssertifikatene som de krypterte forbindelsene i praksis er avhengige av.

Det er mange som utsteder slike SSL-/TLS-sertifikater, men ikke alle har god nok orden i systemene. Dette har blant annet ført til at uvedkommende har fått utstedt sertifikater som domener som tilhører andre, blant annet *.google.com.

Slik uryddig opptreden har ført til at en rekke sertifikatutstedere (CA – Certificate Authority) har blitt utestengt fra det gode selskapet. Det vil si at sertifikatene de utsteder, ikke lenger aksepteres i flere av nettleserne. Det mest kjente tilfellet er Symantec, som skal ha feilutstedt flere titalls tusen sertifikater. Dette resulterte i at selskapet i fjor solgte hele sertifikatvirksomheten, da tilliten var brutt.

Certificate Transparency

For bedre å kunne hindre slike hendelser i framtiden, har Google etablert prosjektet Certificate Transparency (CT), hvor målet er å eliminere flere strukturelle feil i sertifikatsystemet ved tilby et åpent rammeverk for monitorering og revidering av SSL-sertifikater i bortimot sanntid.

Sentralt i dette er en protokoll definert av IETF (Internet Engineering Task Force).

CT skal blant annet gjøre det umulig, eller i alle fall veldig vanskelig, for sertifikatutstedere å utstede et sertifikat til et domene, uten at dette vil være synlig for eieren av dette domenet. Dette fordi sertifikatene registreres i logger som domeneeiere kan overvåke.

Helt nytt er dette ikke. Allerede fra 1. januar 2015 begynte Google å kreve at EV-sertifikater (Extended Validation) måtte støtte CT, for at de skulle støttes av Chrome.

Obligatorisk

– Fra 1. mai i år kom det krav om at alle TLS-sertifikater må støtte Certificate Transparency for å bli akseptert av Chrome, forteller fagansvarlig i for sikkerhetssertifikater hos Buypass, Mads Henriksveen, til digi.no.

Også andre nettleserleverandører, blant annet Apple, skal innføre lignende krav.

Buypass er Norges eneste sertifikatutsteder og er selvfølgelig direkte berørt av alle de endringene som har skjedd innen dette økosystemet de siste årene, inkludert CT.

– CT-loggene er en viktig del av Certificate Transparency. Det er det vi forholder oss til, ved at vi registrerer sertifikatene våre i CT-logger. Men for testmiljøer er det mer begrenset tilgang på loggene. Skal vi verifisere at våre løsninger fungerer og fordeler sertifikater på riktig antall logger, og så videre, så må vi liksom jukse litt når vi driver og tester, forteller Henriksveen.

Han forteller at det bare er Google som har en test-CT-logg som fungerer uten at sertifikater blir tilgjengeliggjort.

Studentoppgave

– Vi tenkte derfor litt på hva som skal til for å sette opp en slik CT-logg, og lurte på om det kunne være en interessant oppgave for studenter ved NTNU på Gjøvik, sier Henriksveen.

– Jeg sitter jo selv på Gjøvik og ser bort på NTNU og vet at det er mye flinke folk der.

Det var også en annen, relatert ting som Buypass hadde tenkt litt på.

– Når nå alle TLS-sertifikater blir publisert i CT-logger, er dette en mulighet for aktører som oss å følge litt med på hva som skjer, hva som blir utstedt av sertifikater globalt på domener som vi er interesserte i, eller som våre kunder er interesserte i, forteller Henriksveen.

– Hvordan er det å utnytte den monitormekanismen som ligger i dette økosystemet? Så det tenkte vi at NTNU-studentene kanskje kunne hjelpe oss med å finne ut.

Oppgaven til studentene var ikke mer detaljert beskrevet enn dette.

Studerer informasjonssikkerhet

Det var studentene Eivind Storsveen Berg og Simen Lybekk som valgte denne oppgaven. Begge studerer informasjonssikkerhet ved NTNU på Gjøvik. De presenterte rapporten sin, «Getting started with Certificate Transparency Servers and Tools», ved universitetet i begynnelsen av juni.

– Først måtte vi sette oss inn i selve teknologien. Deretter satte vi opp en CT-loggserver. Vi bestemte oss for ikke å forsøke å skrive noe slikt selv, fordi det er veldig mange krav til denne typen logger. Det beste valget var derfor å se hva som finnes av åpen kildekode der ute, og så finne ut hvilken som passet best med ønskene til Buypass og hvordan den best konfigureres, forteller Berg til digi.no.

– Deretter skrev vi en slags guide for hvordan en slik CT-loggserver kan settes opp for testformål. Vi håper at Buypass kan få bruk for dette til å sette opp en tilsvarende server.

Lite informasjon tilgjengelig

Studentene fant underveis ut at det ikke var veldig mye informasjon om dette der ute.

– Vi fant to servere som var basert på åpen kildekode. Den ene het bare Certificate Transparency og er lagd av Google. Den andre heter Trillian og er også i all hovedsak lagd av Google-folk, forteller Berg.

Trillian er betydelig nyere og ifølge Berg kan det virke som at mye av utviklingsinnsatsen har beveget seg mye fra den gamle serveren og over til Trillian.

– Men den nye serveren var veldig dårlig dokumentert. På Github-siden ble det forklaring litt om hvordan man kunne kjøre tester på den, men alt annet måtte vi egentlig finne ut av selv. Så det var Trillian-serveren vi endte opp med å skrive en guide for, forteller Berg.

Ble utdatert

Dette var nok et heldig valg, for like før Berg og Lybekk skulle levere rapporten, ble det lagt ut et verktøy i repositoriet til Trillian, som har som formål å overføre data fra den gamle løsningen og over til Trillian.

– Der omtalte de den gamle serveren som «legacy», altså utdatert. Så i praksis så finnes det nå bare én slik server basert på open source, sier Berg.

Studentene valgte ikke å se på eventuelle løsninger med lukket kildekode.

– For det første var det enklere med open source for vår del. Som en del av det å finne ut hvordan vi skulle sette den opp, måtte vi se på kildekoden for finne API-ene vi måtte bruke. I tillegg var det ellers usikkert angående betaling for lisenser i testmiljøer. Så det virket som det beste valget var å gå for open source, forteller Berg.

Fra «scratch»

– Den andre delen av oppgaven var å sette opp loggmonitoren, for Buypass hadde fortalt oss at de hadde lyst til å se på muligheten for å tilby domeneovervåkningstjenester til selskapets kunder, i tillegg til å bruke den til egne formål, forteller Berg.

– Siden vi ikke med en gang fant noe som så ut til å passe Buypass åpent på nettet, virket det som at det beste ville være å lage vår egen monitor fra «scratch». Denne skrev vi i Python, sier Berg.

Etter hvert viste det seg at studentene hadde oversett at Cert Spotter hadde en funksjonalitet som ville ha oppfylt i alle fall en stor del av kravene som vi hadde.

– Men det manglet litt fleksibilitet, så det var egentlig greit at vi lagde den selv. sier Berg.

Helt smertefritt gikk det ikke. Blant annet opplevde de to studentene at monitoren krasjet i blant. Årsaken viste seg å være at enkelte sertifikater inneholdt hele navnet på landet i landfeltet, selv om dette egentlig bare skal inneholde to tegn.

Mye Let's Encrypt

Buypass fikk første gang mulighet til å teste monitoren i april.

– Vi tok bare utgangspunkt i alle sertifikater som vi har utstedt sertifikater til i år, altså hoveddomenene, og ba studentene følge med en uke for å se hvor mange sertifikater som ble utstedt på de forskjellige domene. Da fikk vi en liste tilbake som ga oss et inntrykk av hvordan verden fungerer. Vi kikket blant annet på hvilke utstedere som hadde utstedt sertifikater til våre kunder. Fordelingen der var nok ganske typisk – Let's Encrypt var helt klart øverst, forteller Henrikssveen.

Det å sende resultatfilen per epost var samtidig en utfordring for studentene.

– Det var en diger fil med domener, og noen av disse domene lenket til phishingsider. Vi sendte eposten og regnet med at det ville gå greit. Etter en stund fikk vi en epost fra Buypass hvor de lurte på hvordan det gikk med oppgaven, forteller Berg.

Studentene trodde først at kanskje hadde sendt den til feil epostadresse, men de viste seg til slutt at den var blitt stoppet opp i epostfilterne hos Buypass.

Phishingdomener

Berg forteller at også enkelte andre aktører har egne monitorer. I rapporten skulle studentene skrive hva de selv tenkte om videre bruk av teknologien.

Det å bruke den i tilknytning til phishingdomener, og da spesifikt å se etter domener i loggene som er mistenkelig like andre domener, var blant forslagene de hadde tenkt å ta med. Men så oppdaget de at Facebook allerede hadde gjort dette i sju måneder.

Svært fornøyde

Henriksveen kommer med ros til studentene.

– Jeg syns de har løst det hele på en veldig god måte, og de har vært veldig selvgående, noe jeg er imponert over, sier han.

På forhånd var han litt bekymret for at oppgaven kanskje kunne være litt for «rund» i formen.

– Vi var ikke helt sikre på hvordan studenter tenker og om de kanskje heller vil ha en type «gjør A, B, C eller D»-oppgave. Men vi har hatt noen møter underveis og diskutert oss litt fram, så veien har blitt litt til mens vi har gått. Det har vært en bra måte å jobbe på, sier Henriksveen.

Berg har også bare godord å komme med om oppgaven og samarbeidet med Buypass.

– Jeg valgte denne oppgaven fordi den virket faglig interessant og kanskje mer utfordrende for meg enn mange av de andre oppgavene, sier han.

Samtidig har selvgåenheten kanskje vært litt for stor.

– Den kanskje største feilen vi gjorde under hele prosjektet var at vi nok vi burde ha hatt enda mer dialog med Buypass, sier Berg.

Han forteller at selskapet har stilt opp som en veldig bra ressurs underveis, med deltakelse i møter og tilbud om hjelp.

– Men så satt vi og knotet med det helt selv. Vi hadde tenkt å sende dem status-eposter og slikt, men glemte det litt. Så kom plutselig rapporten i stedet – «nå er vi ferdige», sier Berg.

– Jeg syns resultatet ble bra, altså. Selv om vi ikke vet om det var på grunn av eller på tross av dette, smiler Henriksveen.

Flere logger

Det finnes en rekke CT-logger, og for at et sertifikat skal aksepteres, må det bevises at det er registrert i minst én logg. Ifølge Henriksveen kan dette gjøres på i alle fall tre ulike måter, men i det er bare én av disse som fungerer i praksis, noe som skyldes at de to andre avhenger av støtte i enten webservere eller nettlesere, noe som ikke er skikkelig på plass ennå.

Det tredje alternativet er å bake beviset (SCT – Signed Certificate Timestamp) inn i selve sertifikatet. Ifølge Henriksveen er dette en ganske komplisert sertifiseringsprosess, men fordelen er at det bare er sertifikatutstederne som behøver å gjøre noe.

Hvor mange logger hvert sertifikat må registreres i, avhenger av levetiden til sertifikatet. Årsaken er at CT-loggene ikke nødvendigvis er evigvarende, og antallet skal bidra til å sikre at sertifikatet fortsatt er registrert i en CT-logg, selv om én eller flere andre logger av ulike årsaker plutselig forsvinner.