Har du talt dine rod-certifikater i dag?

Styresystemer flyder over med rod-certifikater, som gør det muligt for organisationerne bag at vise den grønne hængelås i browseren, men de færreste aner, hvem organisationerne er.

Hvornår har du sidst kigget på antallet af rod-certifikater i dit styresystem? I denne skribents telefon med Android 5.1.1 er der eksempelvis ca. 160. Flere af dem kommer dog fra samme udsteder, den såkaldte Root Certificate Authority eller CA, som de kaldes. Men også CA'er er der adskillige af.

Og det er et sikkerhedsproblem med de mange CA'er og certifikater, fordi brugeren ikke har en chance for at vide, om de er til at stole på.

»Det er et kæmpe problem, at der kommer kommer alle mulige tilfældige firmaer og organisationer ind fra rundt om i verden. Det er et råddent system,« siger Version2-blogger med forstand på netværkssikkerhed Henrik Kramshøj.

Han bakkes op af Alexandru Balan, Chief Security Researcher hos Bitdefender, som Version2 har mødt i Bukarest i Rumænien.

»Hvis du ser på root-storen på en vilkårlig enhed, så vil du finde en masse certifikater. Hvem fanden er de folk, og hvorfor har de adgang til at dekryptere mine data?« siger Alexandru Balan.

Det er rodcertifikaterne, der blandt andet får den grønne hængelås til at dukke op, når du går ind på netbank.dk. Hængelåsen indikerer, at det med al sandsynlighed er din netbank, der står bag hjemmesiden, og at forbindelsen er nogenlunde forsvarligt krypteret.

Umuligt at vurdere, om en Root Certificate Authority er troværdig

Alexandru Balan påpeger, at en bruger normalt måske kun kommer i kontakt med certifikater baseret på 5-10 af de store CA'er, men at der alligevel ligger langt flere rodcertifikater i styresystemet. Og dermed bliver det altså en ganske uoverkommelig opgave for den almindelige bruger at vurdere, om en CA er til at stole på eller ej.

Hvis en CA enten bliver hacket eller på den ene eller den anden måde er korrupt, og uvedkommende dermed får adgang til at udstede falske certifikater, kan det bruges til man-in-the-middle-angreb. Så selvom hængelåsen lyser flot grønt i browseren, eller andre af brugerens systemer registrerer en sikker forbindelse, så er det ikke længere nogen sikkerhed for, at brugeren kommunikerer med den rigtige server.

Et man-in-the-middle-angreb kan eksempelvis foregå ved at lokke en bruger til at koble på et wifi-hotspot, som hackeren kontrollerer.

Og det er gået galt. F.eks. for hollandske DigiNotar i 2011, hvilket resulterede i, at falske certifikater blev udstedt fra virksomheden. En efterfølgende undersøgelse viste, at målet så ud til at være iranske Gmail-brugere, oplyser Wikipedia.

Så når ofrene troede, de befandt sig på eksempelvis gmail.com - grøn hængelås og det hele - så var det i virkeligheden en ondsindet hackers server, der styrede trafikken mellem brugeren og gmail.com.

Ikke-standard rodcertifikat på Lenovo

Ud over ikke at have styr på sikkerheden - hvilket kan være en næsten umulig opgave, hvis ressourcestærke organisationer virkelig gerne vil ind - så kan andre ting også gå galt. Som da det tidligere på året kom frem, at der var installeret et ikke-standard rod-certifikat på en stribe maskiner fra Lenovo, så reklame-softwaren Superfish kunne lytte med på SSL-forbindelser og indsætte reklamer i brugerens browser.

Det vakte undren, at Lenovo havde installeret software, der kunne opsnappe trafikken i forbindelser, der ellers skulle forestille at være krypterede. Og det gik helt galt, da det kom frem, at rodcertifikatet var signeret på en sådan måde, at det var muligt at trække den private nøgle ud af det. Hvorefter alle og enhver i princippet kunne lave man-in-the-middle-angreb mod Lenovo-brugere med Superfish installeret.

En dodgy CA

Derudover kan CA'en eksempelvis være småkorrupt, eller en helt anden organisation kan vise sig at stå bag CA'en. For eksempel en efterretningstjeneste.

»Når du udveksler certifikater med nogen, så skal du sikre dig, at du stoler på denne person, og validere deres identitet. Og du skal sikre dig, at de er den, de siger de er,« siger Alexandru Balan og fortsætter:

»Det kan være en regering eller måske en ondsindet organisation. Jeg er ikke sikker på, hvor mange der er i stand til at validere alle de certifikater.«

Men hvad kan man så gøre ved det? Henrik Kramshøj synes, det ville være en idé at rydde alle rod-certifikater og så bede brugeren forholde sig til ét certifikat og én udsteder, når brugeren bevæger sig ind på en ny hjemmeside, der forsøger at oprette en sikker forbindelse.

Og som Alexandru Balan påpeger, vil antallet af forskellige certifikater, den typiske bruger skal forholde sig til, nok være begrænset. Den rumænske sikkerhedsforsker mener dog slet ikke, det nuværende system som sådan kan fikses, da det i udgangspunktet fungerer, som det er tiltænkt.

»For at fikse noget skal man definere, at det er i stykker. Og for at definere, at det er i stykker, skal man definere, at det er i stykker ud fra visse standarder. Og standarderne tilsiger, at det er i stykker, hvis en root-CA bliver hacket. Det er ikke i stykker, fordi nogen har et rod-certifikat.«

Der bliver dog også arbejdet på en anden løsning for at begrænse udfordringen med de mange rod-certifikater. I Googles Chrome-browser og i Mozillas Firefox bliver der brugt det, der kaldes certificate-pinning, fortæller Alexandru Balan.

»Chrome og i det store og hele Firefox laver certificate-pinning. Det vil sige, at de kommer med deres egne pakker med rod-certifikater. De stoler ikke på certifikaterne i operativsystemet,« siger han.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Poul-Henning Kamp Blogger

Jeg har endnu ikke set et eneste CA jeg havde grund til at stole på.

Indtil for nogen tid siden ville jeg formodentlig have stolet på et CA kørt af Rigspolitiet i Danmark, men efter den senere tids løgnehistorier fra deres ende er det løb formodentlig kørt.

Det faktum at hele NemID hejset er hængt op på rod-certifikater fra udlandet gør det i min optik langt mindre troværdigt.

  • 17
  • 0
Claus Bobjerg Juul

Hængelåsen indikerer, at det med al sandsynlighed er din netbank, der står bag hjemmesiden, og at forbindelsen er nogenlunde forsvarligt krypteret.

Hvad er nogenlunde forsvarligt krypteret? Og hvem har draget denne konklusion?

Ville det ikke være sejt hvis man som bruger kan overstyre farven af URL'en således at man fx kunne få grøn tekst hvis der er tale om TLS 1.2 eller bedre, gult hvis det er TLS 1/1.1, rød hvis det er SSL.

  • 1
  • 0
Peter Jensen

Firefox med plugin "Calomel SSL Validation" er uundværligt til at vurdere HTTPS-sessioner.

Jeg oplever ofte at jeg selv skal regulere på tilladte ciphers i min browser for at kunne tvinge browseren til at anvende en sikker cipher frem for en default usikker.

Mange servere prioriterer de usikre ciphers over de sikre ciphers og sætter derfor usikre ciphers som default. Jeg kan ikke se anden substantiel forklaring end at det er bevidst gjort for at give statssikkerhedstjenesterne mulighed for at læse kommunikationen samtidig med at det for den almindelige uvidende bruger ser ud som om serveren er sikker.

  • 1
  • 0
Povl H. Pedersen

Jeg konstaterede for nyligt, at en større dansk finansiel virksomhed, som jo alle er under opsyn af finanstilsynet kørte SSLv1 + TLSv1. Intet nyere. Mange andre fejl. Rettede henvendelse til dem, og problemet blev løst i weekenden efter. Det ser ud til at de også anvender en en fin 3-bogstavers underleverandør (dem er der jo flere af).

De tillod så fine algoritmer som TLS_NULL_WITH_NULL_NULL, men også algoritmer som TLS_RSA_EXPORT_WITH_RC4_40_MD5 (40 bit kryptering, og med den defekte RC4 algoritme). Sårbar for FREAK og POODLE.

Så hvis der er nogen der igen kommer og siger at HTTPS og/eller green bar betyder noget med kryptering, så må man skuffe dem. Selvfølgelig kræver ovenstående at browseren supporterer algoritmerne for at få lavet noget downgrade. Så HTTPS er alene med til at give en sikkerhed for at man taler med det rigtige website, og det giver mulighed for (ikke garanti), for at kommunikationen kan krypteres på det laveste niveau som de 2 ender kan blive enige om.

Personligt er jeg også enig i, at man ikke kan stole på root-CA'erne. Der er vel myndigheder i hvert eneste land der har ret til at få udstedt falske certifikater, om ikke andet så med en kendelse. Og så var der historien med det Tunesiske root cert i IE. Hver gang man fjernede det fra trustet root listen, og besøgte en side med et certifikat udstedt fra den tunesiske CA, så dukkede det op i IE igen. Microsoft tillod ikke at man fjernede fremmede staters spion-CA'er.

Så selvom man fjerne CA'erne fra browseren, så ved man ikke hvilke hemmelige CA'er der indlejres i koden, når der tilbydes penge, eller trusler.

  • 5
  • 0
Michael Hansen

Det skulle vel ikke være DIBS betalings API? Gammelt server side java skrammel der ikke vil køre med nogen særlig optimale moderne ciphers, ud fra de ciphers du postede, ligner det hvertfald :P. (til trafik fra DIBS -> Website/service, ikke den anden vej).

(Fikset i Java 8.X, men ja well...).

  • 0
  • 0
Morten Kallesøe

Er der nogen som ved om der bliver arbejdet på et alternativ til CA's?
Eller hele strukturen og måden at få en sikkerforbindelse? f.eks. n-factor auth ved etablering af en https session?
Det kunne også være at bruge nogle felter fra en DNS query, hvad ved jeg, der er sikkert mange måder at gøre det på :)

  • 0
  • 0
Poul-Henning Kamp Blogger

Er der nogen som ved om der bliver arbejdet på et alternativ til CA's?

Det gør der måske, men det har ikke en snebolds chance i helvede for at blive til noget.

CA'er er big business, i bund og grund opkrævning af beskyttelsespenge fra hvem som helst og hvad som helst på nettet, for at levere varm luft.

CA'erne har ikke tænkt sig at den forretningsmodel skal forringes af nogen eller noget.

  • 6
  • 0
Jacob Rasmussen

Er der nogen som ved om der bliver arbejdet på et alternativ til CA's?

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

Med DANE er du dog tilbage til at skulle stole på certifikatet, der beskytter DNS rod zonen. Som jeg lige forstår det, er det dog bedre, end at skulle stole på alverdens obscure regeringer.

https://en.wikipedia.org/wiki/Convergence_(SSL)

Spørgsmålet er hvad der 'først' bliver så standardiseret, at det kommer med i browserne.
Så længe den almindelige bruger er vænnet til bare at klikke 'ok', for at komme ind på siden, er det i hvert fald ligegyldigt hvilken baggrund advarsler kommer af.

  • 1
  • 0
Bent Jensen

Level 0 - Alt uden
Level 1 - Alt nuværende
Level 2 - Alt du selv har sagt OK til, Kun ting som Netbank Eboks
Level 3 - Leveret med OS, og uden mulighed for ændring, som software pakker til Ubuntu ?
Level - Efterhånden som ting bliver komplimentere kan men vel øge level ?

Desuden skulle certifikater vel minimum have 2 tal, som maling. Som at Netbank certifikat kun må røre netbankmappe. Godkendelse level / Adgang til.

Men det skal vel indbygges i OS , et Certifikat til netbank i Ubuntus kan jo ikke installere en ny kerne. Alt dette er meget uspecifik, og nok almindeligheder. Men vi skal nok ikke forvente at udbyder af certifikater vil gøre noget ved det, hvem skal så ?

  • 1
  • 0
Andreas Lorensen

Det kunne være rart hvis man feks kunne downloade en officiel dansk rod-certifikat liste, med CA'ere som var godkendt og kontrolleret af feks datatilsynet eller anden institution.
Og så samtidig sikre at Microsoft ikke skyder nye certifikater ud med deres Windows Update.

  • 1
  • 0
Jesper Kristensen

Ja, CA-systemet er sygt, men vi har stadig ikke et bedre alternativ.

TOFU (Trust On First Use) som artiklen foreslår dur ikke i praksis. Det hører til Blame The Victim-kategorien. Langt de fleste ville ikke ane hvad de skulle svare på spørgsmål om certifikater, og dem som gør vil ikke have tid til at sætte sig ind i alle detaljerne for hver eneste https websted de besøger. Og selv hvis vi antog at brugere på magisk vis var i stand til at forstå detaljerne i TLS og PKI, så ville udsigten til sikkerhedsdialogbokse få en masse websteder, der burde være på https, til at skifte til http, for at undgå dialogboksene.

DANE mangler en metode til at levere den nødvendige information til klienten, på en måde der ikke ligger milevidt under browsernes standarder for tilgængelighed, pålidelighed, performance og privatliv (standarder der i forvejen er ret lave). Browserne har de samme problemer i mindre grad i dag med certifikattilbagekaldelse. Se fx https://wiki.mozilla.org/CA:RevocationPlan og https://www.imperialviolet.org/2014/04/19/revchecking.html

DNSSEC (og dermed DANE) mangler også en fornuftig incitamentstruktur. Alle de entiteter du er afhængig af er officielle monopoler og mangler derfor enhver form for incitament for at varetage dine interesser.

I det nuværende CA-system er der stærk konkurrence mellem browsere, som derfor har incitament til at vedligeholde deres root stores på fornuftig vis, og fjerne CA'er, der ikke gør det godt nok. CA'erne har et incitament til at agere forsvarligt, for at undgå at blive smidt ud af root storesne. Det har de kun fordi der er flere CA'er i disse stores. Det har tidligere knebet med en reel trussel fra browserproducenternes side, da de har haft svært ved at sikre både kompatibilitet og sikkerhed på samme tid. Men de er efterhånden ved at komme efter det, blandt andet ved hjælp af Certificate Transparency, selvom der nok er et stykke vej endnu.

Nogen vil have nationale myndigheder til at vedligeholde root stores, men hvad skulle gøre dem bedre til det end browserproducenterne? Politikere og myndigheder har ikke ligefrem brilieret med deres evne til at forstå kryptering, og en del vil endda mene at det er disse myndigheder der er fjenden.

Convergense har de samme problemer med tilgængelighed, pålidelighed, performance og privatliv som DANE, bare i større udstrækning.

De eneste alternativer der har en chance for at gøre en forskel inden for en overskuelig fremtid er teknikker der bygger videre på CA-modellen som HPKP og Certificate Transparency. HPKP skal man dog lade være med at bruge, med mindre man virkelig ved hvad man laver, da det ellers er alt for nemt at begå pinning suiside.

  • 1
  • 0
Kim Bjørn Tiedemann Blogger

Og det er åbenbart rigtigt svært at være leader i branchen:

http://www.symantec.com/connect/blogs/tough-day-leaders

Bemærk spinnet om "small number of test certificates ... for three domains" og så Googles udlægning af sagen:

https://googleonlinesecurity.blogspot.ro/2015/10/sustaining-digital-cert...

Jeg tror at Certificate transparency er en del af vejen frem.

  • 1
  • 0
Peter Lind Damkjær

Hver gang man fjernede det fra trustet root listen, og besøgte en side med et certifikat udstedt fra den tunesiske CA, så dukkede det op i IE igen. Microsoft tillod ikke at man fjernede fremmede staters spion-CA'er.

Man kan slå automatisk opdatering af rodcertifikater fra, hvis man ikke ønsker denne funktionalitet.

Prøv at søge på "microsoft disable root certificate update"

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