Efterhånden kan min tillid til SSL ligge på et meget lille sted. De seneste tre kritiske fejl SSL-implementationerne er tilstrækkeligt til at råbe vagt i gevær. Men dette er ikke den eneste grund til at miste tilliden til SSL.
Gennem et styke tid har jeg testet flere websteder med Qualys SSL Labs SSL Server Test og det generelle indtryk er deprimerende. Min bank får for eksempel karakteren C, borger.dk får karakteren B og nets-danid.dk får ligeledes et B.
Sidst men ikke mindst har jeg ingen god grund til at stole på de 222 rod-certifikater der er installeret i min browser. Der er flere historier om at CA’erne udsteder suspekte certifikater.
Så SSL, som vi bruger det i dag, giver efter mening ikke den sikkerhed vi har behov for. Så hvad gør vi så?
Det bemærkelsesværdige ved de tre fejl i Apple’s SSL, GnuTLS og OpenSSL er at der er tale om dumme programmørfejl i kode der burde være ligetil at skrive. Det er altså ikke (kun) fordi SSL er specielt svært at implementere, vi er bare for dårlige til at kode.
Så kan man råbe op om bedre kvalitetsstyring og mere code-review og ende ud i an lang diskussion om hvorvidt open source er bedre end closed source. Mit forslag er mere radikalt: Fjern 80% af koden! Det vil sige alle unødvendige ciphers og alle unødvendige udvidelser til den grundlæggende protokol.
Det vil med det samme fjerne 80% af mulighederne for den slags fejl vi har set og det vil automatisk give alle websteder karakteren A, for alle de valgmuligheder som administratorene ikke kan gennemskue er fjernet.
Så skal vi bare finde ud af hvem der skal bestemme hvad der skal understøttes. Jeg tror ikke på komiteer, så jeg vil foreslå at Apple, Google, Microsoft og måske OpenSSL sætter sig sammen og definere den fremtidige protokol. De er ikke valgt ud fra at jeg har tillid til nogen af dem, men at hvis de 3(+1) siger at sådan bliver det, så følger resten efter.
Der er nogle få krav til dem: Der skal vælges op til tre cipher-suiter. En til low-end devices, en standard suite og en til paranoid brug. Alle suiterne skal understøtte forward security. Eventuelt kan der vælges et sæt cipher-suiter til nødstilfælde hvis standard-suiterne bliver brudt. Serveropsætningen skal kunne foretages med en enkelt parameter om nød-suiterne skal tages i brug.
Tilbage er så problemet med certifikater og CA’erne. Hvis det er muligt er self-signed certifikater at foretrække. Det er selvfølgelig ikke muligt for generelle websteder, men kan yde en bedre beskyttelse for en webservice. Istedet for bare at stole på et vilkårligt CA skal applikationen forvente et konkret certifikat.
Til generel brug og på længere sigt sætter jeg min lid til DANE hvor man bruger DNS-systemet som erstatning for CA’erne. Det giver mindst samme sikkerhed som CA’ernes domæne-validerede certifikater og så kan vi nøjes med at bruge CA’erne til at udstede EV-certifikater som et supplement til at de skal findes i DNS.
Dermed kan jeg som domæne-ejer være sikker på at der ikke er en af 222 CA’er der kommer til at udsteder et certifikat for min service. Men der er en bonus-fordel: Med et bliver https noget en webudbyder uden videre kan tilbyde alle sine kunder uden meromkostninger og merbureaukrati. I dag er der (heldigvis) ikke nogle af CA’erne der bare uden videre vil udstede en million certifikater, med DANE er det ikke alene let, det er også sikkerhedsmæssigt uproblematisk. Hvis kunden flytter sit websted vil certifikatet automatisk blive fjernet fra DNS og dermed revoket. På den måde kan vi endelig få SSL alle steder og ikke kun på websteder hvor ejerne eksplicit ønsker det.
Det er min plan for fremtiden: En stærkt forsimplet protokol skal gøre det lettere at overskue implementationen og server-opsætningen og CA’erne skal reduceres til at yde et supplement til en certifikat-model der lægger kontrollen hos domæne-ejerne.
Leave a Reply