Coops it-direktør irriteret over certifikat-træk fra Google

En opgradering til Chrome-browseren betyder, at adskillige danske hjemmesider nu får en rød streg hen over hængelåsen, selvom forbindelsen er krypteret og certifikatet gyldigt. Det gælder blandt andet indgangssiden til Coop Bank.

I den seneste udgave af Chrome har en stribe danske hjemmesider fået en rød streg sat hen over den hængelås, der normalt skal vise brugeren, at der er oprettet en sikker forbindelse til en server. Men selvom hjemmesider, der ikke tidligere har haft det, nu får sat en rød streg over hængelåsen i Chrome, betyder det ikke nødvendigvis, at forbindelsen pludselig er blevet usikker. Men den kan måske blive det.

En Version2-læser har bemærket, at en af de hjemmesider, der har fået en streg over hængelåsen, er coopbank.dk. Det er online-facaden til Coop Bank, hvorfra der kan klikkes videre ind i netbanken. Selve netbanken er en adskilt standardløsning.

»Det, der selvfølgelig er uheldigt, er, at brugerne får et indtryk af, at det er en usikker forbindelse, og at den ikke er krypteret. Og det er ikke tilfældet. Forbindelsen er lige så sikker, som den hele tiden har været,« siger it-direktør i Coop René Munk-Nissen.

Selvom forbindelsen er krypteret, og certifikatet på Coops Banks side er gyldigt, får Chrome-brugere nu alligevel visuelt at vide, at noget er galt, via den røde streg hen over hængelåsen, når de havner på hjemmesiden. Det skyldes, at Google med den seneste opdatering til Chrome-browseren har øget kravene til de certifikater, hjemmesiderne anvender.

Hvis certifikaterne anvender en SHA-1-signatur, og de udløber 1. januar 2017 og frem, kommer der rød streg over hængelåsen fra Chrome version 42. Google anser nemlig hash-algoritmen SHA-1 som et kommende sikkerhedsproblem, og virksomheden vil derfor gerne have luget ud blandt de længereløbende certifikater.

Udløber SHA-1-certifikatet fra 1. januar 2016 til 31. december 2016, betragter Chrome certifikatet som ‘sikkert, men med mindre fejl’. Det resulterer visuelt i en hængelås med en gul trekant over.

Og udløber SHA-1-certifikatet inden 1. januar 2016 - altså i 2015 - dukker der ikke umiddelbart nogen visuelle advarsler op. Det gjorde der i hvert fald ikke i Version2's besøg på cpr.dk med Chrome version 42. Sitet anvender også et SHA-1-certifikat, men det udløber til december i år.

Google meldte SHA-1-udfasning ud i september

Google har varslet tiltaget mod SHA-1-certifikaterne tilbage i september 2014 i et blogindlæg. I tidslinjen i blogindlægget nævnes Chrome version 41 som der, hvor stregen kommer over hængelåsen, men det lader først til at være sket i version 42, hvilket den italienske sikkerhedsekspert Filippo Valsorda bemærker i et blogindlæg om Googles tiltag.

Virksomhedens begrundelse for at stramme skruen mod SHA-1-certifikaterne er, at det nok vil være for let at bryde krypteringen bag certifikaterne i fremtiden.

Specifikt nævner Google truslen om kollisionsangreb som et problem. Det vil sige, at to forskellige input kørt gennem SHA-1-algoritmen producerer det samme output, hvilket er skidt i en kryptografisk sammenhæng.

Sikkerhedsmanden Bruce Schneier har tidligere blogget om netop denne udfordring, der vokser i takt med processorkraften.

Det er gået galt før

Som eksempel på konsekvenserne, når en algoritme (som SHA-1) brugt til signering af certifikater bliver knækket, henviser Google i blogindlægget til et forskningsindlæg fra 2008.

Blandt forfatterne er blandt andet talsmanden for TOR-netværket Jacob Appelbaum. Indlægget handler om en anden hash-algoritme MD5.

Forfatterne fortæller, hvordan de har opdaget en sårbarhed, der som følge af netop hash-kollisioner i MD5 gør dem i stand til at signere et hvilket som helst certifikat og få en browser til at godtage det. Det betyder, at de kan udgive sig for at være et vilkårligt site på nettet, eksempelvis en netbank.

MD5 bliver ikke anset som egnet til at signere SSL-certifikater med længere.

Ved at begynde udfasningen af SHA-1 forsøger Google at komme af med algoritmen, inden angreb bliver praktisk ladsiggørlige som med MD5.

Og det synes direktør i Solido Networks med forstand på netværkssikkerhed Henrik Kramshøj er helt fornuftigt.

»Det er et supertiltag til at forbedre sikkerheden. Hvis man har et certifikat, som løber så længe, og IKKE bruger noget bedre end SHA-1, skal man skifte - så dermed bør man allerede nu tage det skridt at forny certifikatet,« skriver han i en mail.

Coop: Det er irriterende

René Munk-Nissen fra Coop deler ikke begejstringen.

»Jeg synes faktisk, det er lidt irriterende,« siger han.

Til trods for, at Googles fremgangsmåde måtte vække irritation, bevirker den tilsyneladende også, at SHA-1-certifikatet nu bliver opdateret hos Coop. Ikke bare for bank-hjemmesiden, men også for webshoppen, der også har en rød streg over hængelåsen.

»Det er noget, vi arbejder på at få fjernet, så vi ikke går i rødt så at sige. Vi mener ikke, tilstanden er rød, og derfor er jeg lidt generet over den røde farve. Men nu er den der, og jeg medgiver, at det giver noget forvirring, hvilket ikke er heldigt,« siger René Munk-Nissen.

Inden den seneste udgave af Chrome satte en rød streg over hængelåsen i visse tilfælde, var der ifølge tidsplanen i Googles blogindlæg fra 2014 en gul trekant ved hængelåsen. Når Coop ikke har skiftet certifikatet endnu, handler det om prioriteringer, forklarer René Munk-Nissen.

»Vi prioriterer selvfølgelig hele tiden vores it-indsats. Og vi er i gang med det her, så i løbet af nogle ganske få måneder har vi fuldført en opgradering til det nye certifikat.«

Også hos Erhvervsstyrelsen, hvor hængelåsen ligeledes har fået en rød streg, lader Googles tiltag til at have sat skub i certifikatopdateringen. It-driftschef i styrelsen Ole Widriksen oplyser i en mail:

»Det er vigtigt at pointere, at erhvervsstyrelsen.dk stadig tilgås med en sikker forbindelse og altså ikke er usikker at besøge, selv om det ser sådan ud, når man anvender Chrome-browseren. Erhvervsstyrelsen arbejder på en snarlig løsning, der vil give brugerne den ønskede tryghed, og således ikke giver Chrome-brugerne indtryk af, at erhvervsstyrelsen.dk er usikker at besøge.«

En ny og mere sikker hashfunktion i SHA-2-familien er SHA256. Sikkerhedsvirksomheden Qualys blogger mere om SHA256 og udfasningen af SHA-1 her

Version2 har også forsøgt at få en kommentar fra Yousee, der også får en rød streg over hængelåsen i Chrome version 42 som følge af, hvad der ser ud til at skyldes et SHA-1-certifikat, der udløber efter 2016. Det er ikke lykkedes at få en kommentar fra Yousee.

Opdateret kl. 11:09 7. maj 2015
Artiklen var oprindeligt uden en kommentar fra Erhvervsstyrelsen, men i mellemtiden er styrelsen vendt tilbage. Artiklen er således opdateret med en kommentar fra it-driftschef i Erhvervsstyrelsen Ole Widriksen.

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

Med mindre man bruger de aller dårligste udbydere (jeg kigger på jer, StartSSL), er det gratis og hurtigt at skifte hash, de fleste har et kontrolpanel hvor man bare klikker reissue og vælger SHA-2. Det tager 5 minutter, og ikke meget længere at udskifte det på serveren.

Der er hverken grund til at pive eller bruge måneder på at skifte det.

  • 39
  • 3
Casper Bang

Det meldte Google jo ud for over 6 måneder siden, at de gradvist ville stramme skruen fordi SHA-1 er så svag og fordi SHA-2 er understøttet over alt (ja SHA-3 er vel på vej ud i marken allerede?). Det er sikkerhedsmæssigt et godt trk fra Google, så vi rent faktisk kan stole på at kommunikationen er sikker. Der er bare nogle organisationer der misforstår sikkerhed med convenience!

  • 34
  • 2
Sune Foldager

Det tager måske 5 min. at få et reissue, men der kan være flere andre ting der skal ændres rundt omkring afhængig af hvordan deres site er deployet (da thumbprint er ændret), så du kan ikke bare påstå det vil tage dem 5 min. uden at kende nogen detaljer. Hvis det er cloud deployet fx i Azure eller lign. skal der måske også redeployes efter ændret konfiguration.

  • 11
  • 0
Peter Jensen

Serveren er tilsyneladende også placeret lige midt i NSA-land. Derved kan man være 100% sikker på at alle forbindelserne til og fra serveren bliver tappet og gemt for evigt. Det er efter min mening kun en ekstra god grund til at påse at der er seriøs kryptering af brugernes kommnukation med banken, når serveren er placeret et så tosset sted som USA.

  • 14
  • 1
Henrik Pedersen

Deres IT direktør synes at et sikkerhedstiltag, som blev udmeldt for et halvt år siden, der har reel grobund i den virkelige verden, er irriterende?

Hvad får den mand sine penge for? Burde han ikke følge med i branchen, om end lige skimte nyhederne eller lytte med på den nørdede snak i cafeteriet af og til? Eller har han glemt rollen af en CTO, er at skabe bro mellem IT og forretning, og i stedet laller han bare rundt med forretningsdrengene?

Nogle ganske få måneder synes jeg altså også lyder latterligt. Der var en anden gut her inde som kommenterede højere oppe at vi ikke kender deres infrastruktur. SO WHAT? De er sgu da nogle tosser hvis de ikke kan re-issue et certifikat på under en dag (Så har de også rigtig god tid til kaffen!).

Hvad gjorde de måske under Heartbleed? Var de bare lige glade?

Fyr den direktør og få styr på jeres IT sikkerhed. Hvis I også vil drive netbank må I sgu' tage Jer sammen!

Ps. glæder jeg mig til at læse om den næste store skandale-sag når den en dag rammer Coop.

  • 23
  • 3
Jørgen Nielsen

Han meldte ud at nørder ikke er fremtiden i firmaet. Det skal være folk der kan styre oursourcing partnerne, folk med teknisk viden var ikke nogen de ville holde fast i, så de fleste af os har fundet nyt arbejde.

  • 23
  • 0
Benjamin Bach

Jeg skrev i november 2013 til Coop Mobil, at det var for langt ude, at man skulle vælge et password, som så blev sendt ukrypteret over mail.

Ikke nok med det, så oplyste deres kundeservice medarbejder, at han kunne sidde og læse mit password i deres system *).

Med henvisning til, at deres praksis var i strid med deres egne handelsbetingelser, henvendte jeg mig så i den tro, at det kunne ændres.. altså Coop ville opbevare adgangskoder hashet.

Så skrev de: "Tak for dine input. Vi håber en dag at kunne velkomme dig tilbage som kunde". Oversat: Whatever Benjamin.

På baggrund af deres mangel på respekt for it-sikkerhed og groteske reaktioner på henvendelser om de her problemer, så er det meget meget meget bekymrende, at de driver et mobilselskab, en bank, hundredevis af supermarkeder med betalingsinfrastruktur, der flytter milliarder af kroner.. og samler data ind om millioner (?) af danskeres indkøb på de dér latterligt stregkodebrikker med deres dertilhørende totalt uigennemskuelige point-system.

Det er forfærdeligt, at der bliver skåret ned i Datatilsynet, når man samtidig kan konstatere, at en medlemsejet størrelse som Coop kan skide så højt og flot på sikkerhed og på ingen måde ønsker at agere en progressiv spiller ift. "god skik".

*) Daværende kundeservice medarbejder oplyste også at kan kendte "9" andre selskaber, hvor det også var praksis.

Fun fact: Coop.dk bruger både Piwik og Google Analytics samtidig... og RichRelevance, WebTrends og AdWords..

  • 24
  • 0
Mads Vibe Rasmussen

En ting er at man ikke får opdateret sine certifikater til SHA-256, er der ingen undskyldning for. Et helt andet problem er når domæneudbyderne ikke får opdateret deres rod-certifikater, som ens certifikater bliver signet med. -Dette flagge google chrome nemlig også på.

Dette er i øjeblikket f.eks et issue for brugere af Thawte (Verisign->Symantec selskab) EV Certifikater. -Selvom man har fået lavet nye SHA-256 certifikater, så flagges det stadig ud i Chrome da root certsne stadig er SHA-1

  • 4
  • 0
Peter Andersen

Og ja, hos QualitySSL udskifter vi certifikaterne gratis til SHA2 for vores kunder, lige som vi har gjort det gratis ved overgangen fra 1024 bits private nøgler til 2048 bits og også ved heartbleed problemet...

..og du mener det er helt passende at lave et 100% reklame indlæg her i tråden - uden at bringe noget brugbart på banen?

Lige så langt fremme i er med nye certifikater, lige så langt tilbage er jeres markedsføringsafdeling.

  • 10
  • 2
Jakob Møbjerg Nielsen

Et helt andet problem er når domæneudbyderne ikke får opdateret deres rod-certifikater, som ens certifikater bliver signet med. -Dette flagge google chrome nemlig også på.

Er du sikker på det? Rootcertifikater valideres ikke på baggrund af deres signatur, men på deres identitet. Det eneste problem jeg har oplevet, der kunne minde om dette, er en ringe opsat server der har sendt et rootcertifikat med som et intermediate... Og dermed er det ikke et rootcertifikat, for det er ikke self signed, men identiteten var den samme, og effekten var at der kom et certifikat, med en svag signatur, ind i kæden.

  • 1
  • 0
P. Snabe

Jeg er helt på det rene med, at der sikkerhedsmæssigt ikke er ændret noget fra den ene dag til den anden – altså bortset fra at Chrome nu dømmer certifikater med SHA-1 signatur, der udløber efter 1. januar 2017, som usikre.

Men jeg forstår slet ikke René Munk-Nissens holdning – ”Vi prioriterer selvfølgelig hele tiden vores it-indsats”. Han repræsenter en bank, som lever af, at folk har tillid til den. Og lige nu bliver de kunder (og potentielle kunder), der bruger Chrome mødt med ”en besked” om at siden ikke er sikker. Hvis det ikke har prioritet, hvad har så?

Man må da ikke håbe, at deres marketingsafdeling bruger alt for mange på at skaffe nye kunder for tiden – for de bør da nok lige vente med at fyre budgettet af, til det her er fikset – i løbet af nogle ganske få måneder.

  • 8
  • 0
Henrik Bøgh

..og du mener det er helt passende at lave et 100% reklame indlæg her i tråden - uden at bringe noget brugbart på banen?


Det gjorde han faktisk.
F.eks. havde jeg ikke hørt om deres tester før, men nu ved jeg, at jeg skal fraråde folk at bruge den, fordi den ikke gør folk opmærksomme på problemstillingerne omkring RC4... Se f.eks. her. Første billede er QualitySSL's tester. Andet billede er SSLLabs af samme site.

  • 1
  • 1
Pascal Geuns

..og du mener det er helt passende at lave et 100% reklame indlæg her i tråden - uden at bringe noget brugbart på banen?

Det er vist en 100% overdrivelse fra din side, da jeg også gav læseren mulighed for at få relevant information omkring overgangen fra SHA-1 til SHA-2 og mulighed for at teste ens server for at se om man stadig kørte med SHA-1 certifikat og på vores SSL test side er der heller ingen reklamer !

Det kan godt være at du har styr på SSL/TLS setup, men ud af erfaring, ved vi, at mange ville have haft gavn af den information jeg skrev i mit indlæg...

  • 1
  • 4
Pascal Geuns

F.eks. havde jeg ikke hørt om deres tester før, men nu ved jeg, at jeg skal fraråde folk at bruge den, fordi den ikke gør folk opmærksomme på problemstillingerne omkring RC4... Se f.eks. her. Første billede er QualitySSL's tester. Andet billede er SSLLabs af samme site.

Flot indlæg, som viser skribentens viden, men ikke rigtig hjælper andre...

Tråden handler om SHA-1/2 problematikken, det du skriver om handler om cipher problematikken og her må man nøje overveje hvad man gør!
Vi kan hurtig blive enig om, at i den perfekte verden, ville man sætte cipher suiten op så den er 100% sikker, men selv folkene bag SSLlabs skriver på deres site:

The difficulty is that, for public web sites that need to support a wide user base, there is practically nothing 100% secure they can use to replace RC4. We now have no choice but to accept that, no matter what settings we use, some segment of the user base will be at risk.

Desuden erstatter vores QualitySSL tester ikke vores personlige rådgivning, men er tænkt som et nemt og hurtig værktøj til at give et overblik over ens SSL setup.

Vil man vide mere om cipher suites, og hvordan man sætter dem rigtig op i forhold til de brugere som man er "nød" til at supportere, så kan man have gavn af følgende indlæg fra Mozilla

https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurat...

  • 1
  • 2
Jesper Lillesø

Peter:

En stærkere Hash giver da ikke NSA dårligere muligheder for at dekryptere trafik.

Det hænger alene på PKI.

En dårlig hash kunne feks give mulighed for at lave falske certifikater som ser ud til komme fra en rod de ikke gør ...

  • 1
  • 1
Henrik Bøgh

Flot indlæg, som viser skribentens viden, men ikke rigtig hjælper andre...


Jeg er - sjovt nok - ikke enig. Mit indlæg indeholder et fint link til artiklen om RC4 på Wikipedia, hvor man bl.a. kan læse følgende i indledningen:

As of 2015, there is speculation that some state cryptologic agencies may possess the capability to break RC4 even when used in the TLS protocol. Mozilla and Microsoft recommend disabling RC4 where possible. RFC 7465 prohibits the use of RC4 in TLS.

Nu skal man naturligvis ikke bare tage informationer for gode varer, og derfor er der da heldigvis også nogle gode og troværdige kildehenvisninger i pågældende afsnit :)

Tråden handler om SHA-1/2 problematikken, det du skriver om handler om cipher problematikken og her må man nøje overveje hvad man gør!


Nej tråden handler om Googles respons på problemfyldte certifikater, med udgangspunkt i SHA-1/2 problematikken.

Det betyder ikke at vi skal tage skyklapperne på og nøjes med at fokusere på dele af problemstillingen. Dybest set tager jeg blot de holistiske briller på og påpeger et forbedringspotentiale i jeres service - helt omkostningsfrit. Det var så lidt :)

Jeg kan i øvrigt ikke undgå at bemærke, at dit indlæg tilsyneladende er blevet fjernet (?) og at SSLLabs tester kun grader QualitySSL med et B... Men sådan er der jo så meget :)

Er det det korrekte link?


Der var lige smuttet noget. Her er det korrekte link. Beklager.

  • 1
  • 0
Rune Larsen

En stærkere Hash giver da ikke NSA dårligere muligheder for at dekryptere trafik.


Jo, og du forklarer selv hvorfor:

En dårlig hash kunne feks give mulighed for at lave falske certifikater som ser ud til komme fra en rod de ikke gør ...


Hvorved en MitM som NSA kan dekryptere trafik, uden brugerne opdager det.

Men NSA har allerede stjålet, fået udleveret eller hacket de fleste rod-CA-nøgler og kan udgive sig for at være et hvilket som helst website og signere på vegne af stor set alle CA'er. Hvis man vil lave noget NSA-sikkert, så er det kun end-to-end kryptering der dur - glem alt om tillid til rod CA'er og hængelåse i browsere.

  • 2
  • 0
Pascal Geuns

Nej tråden handler om Googles respons på problemfyldte certifikater, med udgangspunkt i SHA-1/2 problematikken.

Ja men så er vi jo enig :-)

Dybest set tager jeg blot de holistiske briller på og påpeger et forbedringspotentiale i jeres service - helt omkostningsfrit. Det var så lidt :)

På med læsebrillerne - når du så læser dit første indlæg en gang til, kan du se, at du direkte fraråde folk at bruge vores tilbud om et nemt SSL check, det er langt fra blot at påpege et forbedringspotentiale i vores service !

SSLLabs tester kun grader QualitySSL med et B... Men sådan er der jo så meget :)

Måske skulle du have læst hele mit indlæg, specielt sidste afsnit med linket til Mozilla siden, så finder du også svaret på hvorfor resultatet falder ud som det gør!

Jeg vil hermed også lige gøre opmærksom på at problematikken med RC4 stadig er på teoretisk plan, som du selv citerer, spekulerer man stadig om nogen har effektiv brudt RC4. Når det er sagt, så vurderer vi løbende vores setup og tilpasser det om nødvendigt.

Jeg forstå dog ikke, at du selv kan være tilfreds med en grade F og SHA1 certifikater i din egen organisation

https://www.ssllabs.com/ssltest/analyze.html?d=fmn.dk
https://www.ssllabs.com/ssltest/analyze.html?d=forsvaret.dk

Problemerne med det SSL setup på de 2 servere kunne du også nemt have fundet ud af hvis du brugte vores SSL tester ;-)

http://www.qualityssl.com/dk/support/ssl-server-test.lasso?url=fmn.dk
http://www.qualityssl.com/dk/support/ssl-server-test.lasso?url=forsvaret.dk

Men ja, SSL/TLS er et komplekst område som er i konstant udvikling og konlusionen må være, at det ikke længere er nok med bare at købe et SSL certifikat til serveren - for derefter at glemme alt om certifikatet indtil den rammer fornyelsesdatoen. Udviklingen på SSL/TLS området sker så hurtig at man nu og fremover bliver konstant nød til at revurdere ens SSL setup for at holde det up to date.

Og det er her jeg stadig mener, at mit indlæg havde relevans, fordi som SSL udbyder - skal man yde den service, at hjælpe sine kunder med at holde deres SSL setup up to date, men det er langt fra alle som tilbyder denne service...

  • 1
  • 1
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize