Det Skandaleramte SikkerhedsLag - og hvad gør vi nu?

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.

Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jacob Pind

da der her for nogen uger siden var er en artikle omkring de forskellige libs håndtering af certifikater, og der var det kun nss og openssl som klare sig igennem med kun en ikke sikkerheds kritisk fejl, polarssl, matrixssl fejlede ganske grumt der, http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large .
Men okey x509 er også noget som en sardist har sat sammen, er horibelt svært at parse den slags.

Men du har ret i det med Dane, kunne vi få CA ude af loopede kunne det hjælp gevaltig på sikkerhed.

  • 2
  • 0
Leif Neland

Men der er en bonus-fordel: Med et bliver https noget en webudbyder uden videre kan tilbyde alle sine kunder uden meromkostninger og merbureaukrati.

Det kræver webhotellet og alle de besøgende kører ipv6, da https ikke kan køre på en delt ip-adresse, dvs mange webadresser på samme server.

Problemet er, at når trafikken er krypteret, er URL'en også krypteret, men webserveren kan ikke vide hvilken virtuel host, den er adresseret til, og hvilken nøgle, der skal dekrypteres med.

Eller også skal server og klient understøtte TLS, hvor "server name" sendes uden for den krypterede del. Men det er ikke tydeligt i f.ex. apache-dokumentationen, om og hvorledes det kan sættes op.

http://stackoverflow.com/questions/7219911/validate-ssl-certificate-on-a... er der modstridende meninger:

> To my knowledge, support for that extension is not yet in widespread deployment. – cdhowie

> All major browsers and almost all (if not all) TLS libraries support it. I believe, all major servers support it as well. – Eugene Mayevski 'EldoS Corp

  • 0
  • 1
Leif Neland

Nå, ikke al apache-dokumentation er up-to-date.
https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI er opskriften til TLS.

The client browser must also support SNI. Here are some browsers that do:

Mozilla Firefox 2.0 or later
Opera 8.0 or later (with TLS 1.1 enabled)
Internet Explorer 7.0 or later (on Vista, not XP)
Google Chrome
Safari 3.2.1 on Mac OS X 10.5.6

Unfortunately, SNI support isn’t available on Windows XP, even in IE8. IE relies on SChannel for the implementation of all of its HTTPS protocols. SChannel is an operating system component, and it was only updated with support for TLS extension on Windows Vista and later.

  • 1
  • 0
Peter Makholm Blogger

"Efterhånden kan min tillid til SSL ligge på et meget lille sted." Typo?

Nej. Det er klart at OpenSSL er specielt hårdt ramt på grund af alvorligheden af Heartbleed, men de andre SSL implementationer har haft problemer af samme type. Og fejl i implementationerne er kun en af de tre ben min mistillid bygger på.

En anden ting, hvilke alternativer findes der til OpenSSL, der kan bruges med fx Apache etc?

Til Apache kender jeg til mod_gnutls og mod_nss. Den sidste har jeg først fundet her til morgen.

  • 3
  • 0
Poul-Henning Kamp Blogger

Jeg er stort set 100% enig Peter, men du overvurderer DANE en anelse:

"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."

Til gengæld bliver du nødt til at stole på at din upstream domain-adminstrator ikke signerer nogle falske certifikater der kan bruges til DNS-race imod de rigtige svar.

Vi kan diskutere op og ned om det er en større eller mindre risko end CA-mafiaen, men det betyder dels en "lokalisering" af angrebsfladen som f.eks bringer FE og DK-Hostmaster i søgelyset for .dk domæner.

Det retter også projektøren direkte imod rodcertifikatet, som f.eks jeg efter nærmere eftertanke har konkluderet ikke kan og ikke er beskyttet imod USAs efterretningstjenester.

En central fejl i hele denne problematik er at browsere bare viser en lukket hængelås, som betyder "nogen vi stoler på siger at det er OK", uden at angive hvem det er vi stoler på som nikker lodret på vores vegne.

Hvis browsere gik over til at vise hvilket rodcertifikat tænder den grønne hængelås, tror jeg at rigtig mange brugere ville give sig til at undre sig hvis Google pludselig var "godkendt" af den Tyrkiske regerings "sock-puppet" CA.

Mht dit forslag om styregruppe: Jeg ville være meget mere tryg ved Bruce Schneier, Dan Kaminsky og Kevin Mitchnick og vi ville helt sikkert få en beslutning meget hurtigere.

  • 10
  • 0
Peter Makholm Blogger

Det kræver webhotellet og alle de besøgende kører ipv6, da https ikke kan køre på en delt ip-adresse, dvs mange webadresser på samme server.

Det er stort set kun MSIE på Windows XP der ikke understøtter SNI, som er den udvidelse der kræves for at kunne bruge forskellige certifikater på samme IP-adresse.

Så mangel på SNI er efter min mening ikke længere en relevant undskyldning.

For discount webhosting i stor skala er det måske en større forhindring at det kan være noget besværligt at sætte op så det skalerer ordentligt. Det er let nok når man bare skal sætte en håndfuld certifikater op i en statisk opsætning, men hvis man har en meget dynamisk opsætning hvor en server skal kunne håndtere 1000+ hosts og der skal tilføjes hosts uden genstart af serveren, så kommer standard-udgaven af OpenSSL til både Apache og nginx til kort.

... men det kan gøres.

  • 0
  • 0
Peter Makholm Blogger

Mht dit forslag om styregruppe: Jeg ville være meget mere tryg ved Bruce Schneier, Dan Kaminsky og Kevin Mitchnick og vi ville helt sikkert få en beslutning meget hurtigere.

Jeg er helt enig i at disse tre personer nok vil kunne tage en hurtigere og bedre beslutning end repræsentanter fra Apple, Google og Microsoft.

Grunden til at jeg vælger Apple, Google og Microsoft er at minimere tiden der går fra vi har et pænt dokument der beskriver en beslutning til at en tilpas stor del af klienterne er tvangsopdateret til at server-folket ikke bare kan side afventende tilbage.

En (u)hellig alliance af de tre firmaer vil næsten kunne sætte en flag day og sige at efter 7. april 2016 vil browserne ikke længere understøtte TLS under version 2.0.

Under alle omstændigheder vil successen kræve at netop de tre firmaer vælger at implementere en ny standard og vælger at sætte hårdt ind for at reducere brugen af den nuværende urskov af cipher suiter og SSL options. Derfor deler jeg heller ikke Maciej Szeligas bekymring da det uanset hvem der skriver specifikationen er Apple, Google og Microsoft der skal implementere den for langt de fleste brugere.

  • 4
  • 0
Poul-Henning Kamp Blogger

En (u)hellig alliance af de tre firmaer vil næsten kunne sætte en flag day og sige at efter 7. april 2016 vil browserne ikke længere understøtte TLS under version 2.0.

Det argument tror jeg ikke en meter på: Hvis de endelig sætter en "flag day", bliver det tidligst 19 januar 2038 eller noget i den stil, for de har alt for store interessekonflikter til at turde pisse deres kunder af i nogen nær fremtid.

Se blot hvorledes Microsoft endte med at prøve at bestikke deres XP brugere.

Dette er i sandhed en "Tragedy of the Commons" og derfor er det kun græsrødderne der kan løfte opgaven.

  • 3
  • 0
Pelle Söderling

Nogen som har erfaringer med at bruge RSA i javascript (ved der er flere implementeringer heraf) hvor man basicly leverer en public key med ud som man så bruger til kryptering af dataene inden de sendes til serveren.

Som jeg ser det kunne det bringe kontrollen 100% tilbage til os udviklere, såfremt der ikke er eks. performance-problemer involveret, andre issues ved javascript clientside kryptering eller noget jeg har overset.

  • 1
  • 2
Thue Kristensen

Min bank får for eksempel karakteren C, borger.dk får karakteren B og nets-danid.dk får ligeledes et B.

Ah, men de bruger alle sammen NemID. Og NemID er ikke sikrere end den svageste side som bruger NemID, i det du kan bruge passwords og engangskoder derfra til at logge ind på fx din bank.

  • 1
  • 1
Thomas Larsen

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.

Check lige findsmiley.dk ud hvis du har lyst til at blive endnu mere deprimeret:
https://www.ssllabs.com/ssltest/clearCache.html?d=findsmiley.dk&ignoreMi...

  • 0
  • 0
Daniel Udsen

Obligatorisk xkcd link http://xkcd.com/927/

Løsningen er aldrig en ny og bedre standard, især når problemet ikke var manglende standardisering fra starten. Og ideen om en WHATWG lignende løs alliance er nok heller ikke en løsning når man ser på det kaos de fik sluppet løs.

Dybest set er problemet manglende test og validering, eller at valideringen kun foretages imod ting der skal gå rigtigt og ikke imod hvad der kan gå galt. Så du kommer nok ikke udenom at fokusere mere på test/QA end standarder.

Mon de bruger flere certifikater eller sender forskellige certifikater afhængig af hvem der spørger?

Jeg får også serveret det svenske certifikat og firefox viser en advarsel så går udfra du har ret i at udenlandske IP'er bliver sent via en svensk server. Webfarme er idag lidt mere komplekse end i de gode gamle dage hvor du ikke havde flere lag af acceleratorer og "reverse proxy's" involveret, og det er selvfølgeligt et af problemerne.

Det at en IP ssl certifikater certifikere hosts og ikke forfattere er så vidt jeg ved et af de praktiske af problemet der er med at få det sat til korrekt alle vegne.

  • 0
  • 0
Finn Christensen

Re: Check lige fødevarestyrelsen!

Mere sjov og spas:
https://postdanmark.dk/ (certifikatet er udstedt til det svenske "posten.se")

Kan fortælle om et følsomt område, hvor det står/stod fælt til... http://www.tidtilalt.dk/bestil-tid-til-laegen.htm

Tidsbestilling, hvor man opgiver sit CPR og måske fortæller lægen og sine skrøbeligheder før konsultation. Jeg oplevede site som lidt amatøragtig og testede i efteråret 2013 med Qualys SSL Labs - fik bl.a. 'outdated SSL version' mm. samt vist karakteren D-G, kan kun huske, at den var alt for høj og alarmerende..

Printede testresultatet og gav det til min læge, da jeg alligevel skulle forbi. Lægen fatte vist ikke helt det vitale mht. CPR eller datasikkerhed.

Vi har her personlige+følsomme data..
- hvor mange år har det hul været åbent og aktivt ?
- hvem pokker er den idiot, der har godkendt det makværk ?
- hvor er vores højt besungne datatilsyn henne ?

  • 1
  • 0
Leif Neland
  • 0
  • 0
Peter Makholm Blogger

Løsningen er aldrig en ny og bedre standard, især når problemet ikke var manglende standardisering fra starten.

Det kommer an på hvad vi opfatter som manglende standardisering. Det nuværende tag-selv bord af cipher-suiter som SSL i øjeblikket tillader kalder jeg ikke en standard men en zoologisk have.

Det burde være klart ud fra mit blogindlæg at jeg mener at problemet er den alt for store valgfrihed i SSL. Dermed er problemt netop standarden og dette problem skal netop løses ved at lave en ny og bedre standard.

En ny standard skal for alt i verden ikke udvide valgfriheden, tværtimod. Den skal ryde op i hvad der er tilladt efter klienten og serveren er blevet enige om at begge ender udnerstøtter den nye standard.

  • 0
  • 0
Peter Makholm Blogger

Jeg er stort set 100% enig Peter, men du overvurderer DANE en anelse:


Det er klart at man ikke skal oversælge en ny sikekrhedsmodel. Derfor skal jeg gerne understrege at DANE i sig selv ikke er en erstatning for noget som helst andet end de nuværende domæne-validerede certifikater.

Skal man have bedre sikkerhed end at serveren og DNS-domænet hører sammen kan hverken DANE eller domæne-validerede certifikater stå alene. Det gør det heller ikke i dag hvor organisationer der virkelig kræver sikker identifikation forventes at bruge EV-certifikater. Forskellige former for certificate pinning er en anden metode, der netop forhindrer at google.com-certifikatet pludselig er udstedt af en suspekt tyrkisk CA (hvilket for højprofil-websteder tildels løser dit problem med hængelåsen).

Domænevaliderede certifikater og DANE giver stort set samme sikkerhed. Den store forskel er hvornår man skal angribe DNS for at kompromitere sikkerheden. For domænevaliderede certifikater skal man angribe CA'ets resolver i det øjeblik certifikatet skal valideres, mens DANE kræver at man angriber brugerens resolver i det øjeblik forbindelsen valideres. Dermed vil jeg hellere sætte min lid til DANE end domænevaliderede certifikater.

Du nævner en række aktøre der let kan angribe DANE. Det er min påstand at de endnu lettere vil kunne angribe modellen med domænevaliderede certifikater. Det er et langt mere lokaliseret angreb der skal til for at bruge et længervarende falsk certifikat.

For nogle aktøre er det nok lettere bare at læne sig en smule op ad CA'et. Det tror jeg i hvert fald gælder for de aktøre som du antyder har adgang til DNSSEC rodnøglen. Et certifikat udsted af en CA vil simplethen i en lang række tilfælde være mere diskret end at kompromitere DNSSEC generelt.

For folk der har brug for bedre sikkerhed end domænevaliderede certifikater og DANE vil DANE stadigvæk være et godt supplement der øger sikkerheden, da det giver en mulighed for domæneejeren for at styre certifikater. Det er ikke en erstatning for det der idag giver dem en højere sikkerhed, det er et suplement der giver dem en endnu bedre sikkerhed.

Derfor er jeg ikke umidelbart enig i at jeg overvurderer DANE. Det virker mere som om det er dig der overvurdere hvilken sikkerhed som det er domænevaliderede certifikater i dag giver elelr overfortokler min holdning til DANE. I sidste fald håber jeg at ovenstående har afklaret det.

  • 0
  • 0
Log ind eller Opret konto for at kommentere