Rapport: Chromes heartbleed-beskyttelse ”fuldstændigt i stykker”

Den populære browser Google Chrome overser 98 pct. af tilbagekaldte certifikater, hvilket gør brugeren blind overfor Heartbleed-angreb, konkluderer en rapport.

Google Chrome er kun i stand til at blokere for to procent af de certifikater, der er tilbagekaldt på grund af den såkaldte Heartbleed Bug. Det konkluderer en nyligt publiceret rapport, skriver Ars Technica.

Problemet findes i browserens CRLSet, der er en liste over tilbagekaldte certifikater for websites. Ifølge rapporten indeholder listen kun to procent af de tilbagekaldte certifikater og overser tusindevis af TLS- og Secure Sockets Layer-certifikater, som er blevet tilbagekaldt efter Heartbleed-sårbarheden blev opdaget.

Læs også: Ekspert til Google: Dårlig idé at droppe sikkerhedsstandard i Chrome

Rapporten er lavet af Gibson Research Corporation, som har gjort den tilgængelig online.

»Vi ved, at Chromes CRLSet indeholder højest 2% af de certifikater, der pt. Er tilbagetrukket af internettets certifikatudstedere. Chrome vil blindt stole på de resterende 98% af internettets tilbagetrukne og endnu ikke udløbne certifikater. Selvfølgelig bliver der tilbagetrukket nye certifikater hver dag, hvoraf Chrome aldrig vil være klar over 98%,« skriver GRC i et blogindlæg.

Efter historien er kommet frem, har Google-ingeniør Adam Langley svaret på kritikken i et blogindlæg. Her påpeger han, at CRLSet aldrig har været perfekt, men at det er bedre end de tilsvarende løsninger i andre browsere.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Casper Bang

Adam Langley's svar giver Ok mening, altså, at det skaber nogen problemer fordi det er en meget stor liste der skal holdes opdateret og skubbes ud til folk.

Meeeen... kunne man ikke blot lade funktionen være lazy asynkron, hvor request til en ukendt SSL side samtidigt spawner et request til en letvægt REST service med et beefy cache system? Advarslen vil potentielt dukke op et par sek. senere, men stadig være gavnlig. Et mere stringent alternativ kunne være at lade servicen fungere som proxy, eller måske ligefrem benytte en speciel DNS til formålet.

  • 4
  • 0
David Rechnagel Udsen

Ars Technica-artiklen nævner kun Firefox:

Mozilla's Firefox browser, by contrast, automatically blocked the revoked.grc.com certificate several days before Chrome's developers added a manual override, the blog post said.

Ændring: Hvorfor ødelægger Version2 apostrofer?

  • 0
  • 0
Peter Makholm Blogger

Folkene bag chrome har valgt at det tager for lang tid at tjekke om certifikater er blevet revoket. Derfor er tjekken som standard slået fra. Det kan slås til under 'advancerede settings' -> HTTPS.

Da jeg skrev mit seneste blogindlæg om DANE testede jeg de browsere jeg lige havde tilgængeligt. Firefox og Safari afviser pænt det certifikat jeg har fået revoked hos AlphaSSL, men Chrome godtager det indtil jeg eksplicit beder den om at teste det.

I kan selv tjekke med andre browsere på https://revoked.hacking.dk/

  • 7
  • 0
Jacob Nordfalk

Har læst artiklerne, her kommer et kort og forståeligt resume:

Problemet er at hvis en bruger er ude for et man-in-the-middle angreb, så kan hackeren med stor sandsynlighed også sørge for at blokere for browserens check for om certifikatet er blevet trukket tilbage... og så vil browsere bare antage er certifikatudstederens server er nede og godkende certifikatet (=soft-fail revocation checking).

Adam Langley mener derfor, at hele systemet (med at browseren på brugstidspunktet spørger certifikatudstederens server) er værdiløst og kun bidrager til at gøre internettet langsommere.

Adam Langleys/Chromes løsning siden 2012, CRLSet, består i at i stedet at skubbe de vigtigste af sådanne tilbagetrækninger ud til browserne i en browseropdatering.

Problemet er at en opdatering med ALLE tilbagetrækninger inden for en årrække kommer til at fylde ~300 MB, derfor tager CRLSet kun 'de vigtigste'.

Adam Langley arbejder derfor på at få lavet en skelnen mellem 'vigtige' tilbagetrækninger og den langt større gruppe af administrative tilbagetrækninger (der bare sker fordi kunden ikke har betalt til certifikatudbyderen til tiden), men har der ikke været fodslag i branchen til endnu.

  • 6
  • 0
Casper Bang

Problemet er at en opdatering med ALLE tilbagetrækninger inden for en årrække kommer til at fylde ~300 MB, derfor tager CRLSet kun 'de vigtigste'.

300MB over 5 år, betyder at en bruger vil skulle hente 5MB delta-opdateringer om måneden, eller lidt over 1MB om ugen.

De "vigtigste" CRLSet ser for mit vedkommende således ud p.t. i version 1609 og fylder imellem 250-300KB. Dekodet får man et hieraki af SHA-256 hashes af SubjectPublicKeyInfo, der ser således ud.

  • 1
  • 0
Mikael Barfred

Der afvejes altså god sikkerhed mod: * Nogle få millisekunders ekstra ventetid ved besøg på HTTPS sider for at lade browseren checke revokering i real-tid * At lade en fuld browserinstallation indeholde nogle få hundrede MB ekstra (kun fuld installation, opdateringer kan klares inkrementelt)

Og i den afvejning taber hensynet til sikkerhed!? Der er da noget helt galt med prioriteringen her.

Iøvrigt er der vel ikke noget, der forhindrer, at man implementerer både et real-tids check og en CRLSet liste i browseren. Hvis real-tids check ikke lykkes (pga. ondsindet blokering eller revok. site er nede), og cert. ikke er i CRLSet listen, så skal browseren advare brugeren med "Certifikatets gyldighed kan ikke garanteres (mere info her... blah, blah). Er du helt sikker på du ønsker at fortsætte?"

  • 1
  • 1
Uffe Seerup

Iøvrigt er der vel ikke noget, der forhindrer, at man implementerer både et real-tids check og en CRLSet liste i browseren.

Præcist! Men i jagten på at lave den hurtigste browser har Google prioriteret sikkerheden ned.

Internet Explorer (eller rettere: Windows, idet IE blot benytter Windows Crypto API til revocation checks) benytter allerede en prioriteret rækkefølge:

  1. CryptoAPI determines whether the certificate is included in the Untrusted certificate store. All certificates in the Untrusted certificate store are explicitly designated as disallowed certificates.

  2. If the certificate included a stapled OCSP response and the stapled response is time valid, use the stapled OCSP response to valid the revocation status of the certificate.

  3. If a CRL with the matching issuer name and optionally the same IDP is already in the CA store, use that version of the CRL.

  4. If a stapled response or previously downloaded CRL is not available, then CryptoAPI must attempt URL retrieval to determine the revocation status of the certificate.

  5. The URLs for OCSP and CDP are built in the following order:

    a. OCSP URLs from Group Policy

    b. OCSP URLs from the authority information access extension

    c. CRL URLs from the CDP extension

(http://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx)

Der er vistnok også for IE en tilsvarende svaghed som består i, at hvis der ikke modtages svar fra revocation check så tillader IE at der køres videre. Dermed kan en man-in-the-middle benytte et blokeret cert hvis han forhindrer revocation checks i at blive besvaret.

Stapled responses ligner den bedste måde at sørge for at browseren ikke bliver forsinket af OCSP/CRL opslag og samtidigt at maskiner i Verden ikke skal have fuldstændige CRL'er for hele Internet.

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