kim tiedemann bloghoved

Så skal der bestilles SSL certifikater

Det har længe været kendt, at SHA-1 hashing algoritmen begynder at vise alderdomstegn og må betragtes som værende så usikker, at den ikke længere skal være vores førstevalg, når der skal implementeres sikkerhed. Den lider samme skæbne som MD5 algoritmen, som vi begyndte at bevæge os væk fra for snart mange år siden.

Allerede i 2005 blev det påvist at der findes en metode til at genere en hash kollision, som er 2000 gange hurtigere end brute force.

Bruce Schneier skrev for 2 år siden et blog-indlæg om at omkostningerne ved at producere en hash-kollision til stadighed bliver billigere og billigere. Det skyldes, at hardwaren fra i dag er billigere næste år grundet Moores lov. I blogindlægget estimeres, at det vil være muligt at skabe en kollision for USD 43.000 i 2021.

SSL certifikater

I SSL certifikater benyttes SHA-1 hashing algoritmen til at skabe en hashværdi af certifikatet, som efterfølgende signeres af det certifikat, som befinder sig i stien ovenover (typisk et intermediate eller CA certifikat). Når det viser sig praktisk muligt at skabe en hash-kollision kan man altså skabe et nyt certifikat, som har samme SHA-1 hash værdi som et andet certifikat. Det bliver med andre ord muligt at skabe et rogue certifikat, som kan bruges i stedet for det oprindelige (og rigtige) certifikat.

I 2008 viste forskere at dette kunne lade sig gøre med MD5 hashing algoritmen, og i nogle år har IT sikkerhedsfolk haft samme bekymring for SHA-1.

Microsoft reagerer

Den 12. november sidste år valgte Microsoft at fraråde brugen af SHA-1 hashing algoritmen og tillader ikke at root CA efter 1. januar 2016 udsteder certifikater med SHA-1 hash algoritmen. Microsoft har ikke konkret beskrevet, hvad de har tænkt sig at gøre med fx brugergrænsefladen i Internet Explorer.

Google reagerer

I et blogindlæg fra den 5. september skriver Google, at de langsomt (men hurtigere end Microsoft) vil udfase brugen af SHA-1 algoritmen. Det vil de gøre ved at deres Chrome browser over tid vil vise sikkerhedsadvarsler overfor brugere af sites, som benytter SHA-1 i deres SSL certifikat. Deres politik er, at Chrome vil vise mere og mere alvorlige sikkerhedsadvarsler for brugeren, for certifikater som udløber efter 1. januar 2016 og som stadig benytter SHA-1 algoritmen. Dette rangerer fra "lås med trekant advarsel" til den helt alvorlige "lås med rød streg over".

Illustration: Privatfoto

De offentlige sider

Der er mange offentlige sider der benytter SSL certifikater med SHA-1 hashing algoritmen.

Jeg har listet en række af dem her (i parentes vises gyldighed for certifikatet):

Jeg kunne kun finde et site hvis certifikat allerede benytter en SHA-2 hashing algoritme:

Som det kan ses vil kun e-boks.dk, virk.dk og ug.dk blive påvirket af ændringerne i Chrome, da de andre sites er tvunget til at skifte certifikat inden 2016.

For borger.dk gælder det, at indhold for selvbetjeningsløsninger tit vises i en iframe, og hvis disse sites benytter certifikater med SHA-1 algoritmen, så vil Chrome formentligt også vise en fejl (det fremgår dog ikke eksplicit af deres blogindlæg).

De berørte sites kan selvfølgelig vælge at genudstede deres certifikat, men historien peger desværre på, at SSL certifikater på offentlige sites når at udløbe, inden de skiftes: SU-lån
, PET og borger.dk

Er det fornuftigt?

Der er megen debat på nettet om Googles beslutning. Er det for radikalt, når man tager i betragtning at SHA-1 endnu ikke i praksis er usikker?

Jeg kan godt lide, at Google bekymrer sig for Internettets sikkerhed, hvor de senest har valgt at benytte brug af SSL som en faktor i deres ranking algoritme.

Jeg synes dog, hastigheden hvor med det implementeres er lidt voldsom. Specielt når man tager i betragtning at Chrome allerede om to versioner begynder at vise sikkerhedsadvarsler for certifikater, som udløber i 2017. Google har valgt at lave en trinvis implementering (de kalder det slow motion emergency) i stedet for en big bang løsning, og dermed tvinge sites der har et 2017 certifikat til at tage stilling snart.

Ovenstående liste af sites med SHA-1 hash algoritme certifikater viser også, at det er nødvendigt. På trods af at vi har vidst, at SHA-1 har begrænset levetid og CA/Browser forum har frarådet brugen af SHA-1 siden 2011, så udstedes der stadig gladeligt certifikater der benytter SHA-1 hash algoritmen. Så sent som i år blev certifikaterne til nemlog-in.dk og ug.dk udstedt med SHA-1 hash algoritmen.

Jeg synes at historien viser, at der er behov for at gribe ind. Certifikatudstederne ser ikke ud til at kunne håndtere dette selv og jeg mener, at implementeringen faktisk er en god måde at tvinge udbyderne til at udfase SHA-1 - ved at brugerne gradvist bliver gjort opmærksom på sikkerhedsproblemerne - man har jo ikke lyst til at handle et sted der har en adresselinje med rød streg igennem.

Er det fornuftigt? Hvad synes du?

Ps. Du kan bruge shaaaaaaaaaaaaa.com til at teste dit nuværende SSL certifikat.

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Larsen

God artikel om et væsentligt emne - og fint med vinklingen på offentlige myndigheder som i mine øjne er særligt slemme til at være laaaangt bagud med TLS/SSL-sikkerheden. Det skyldes nok at de ikke har nogen medarbejdere in-house der har forstand på den slags og de skal vel nærmest gennemføre et EU-udbud bare for at få en konsulent til at komme forbi og skifte SSL-certifikat eller ændre på cipher-opsætningen.

Apropos cipher-opsætning kunne det ikke være relevant at sætte spotlight på hvor mange offentlige hjemmesider der kun tillader brug af RC4-kryptering som Microsoft mig bekendt også fraråder? Sidst jeg tjekkede kunne man kun bruge RC4 på netsteder som borger.dk, skat.dk osv.

Uffe Seerup

propos cipher-opsætning kunne det ikke være relevant at sætte spotlight på hvor mange offentlige hjemmesider der kun tillader brug af RC4-kryptering som Microsoft mig bekendt også fraråder?

Det er noget med, at nogle endnu ikke udfasede versioner af Safari + OS X ikke kan bruge alternativerne. Men man kan vistnok "prioritere" så det kun vil være de OS X versioner som ikke kan andet end RC4 som bliver "usikre".

Thomas Larsen

Det er noget med, at nogle endnu ikke udfasede versioner af Safari + OS X ikke kan bruge alternativerne.


Tak for svaret. Det er nemlig rigtigt at man kan prioritere så der stadig er usikre fallback-muligheder til bagstræberne. Det er derfor efter min mening ikke noget argument for at så mange offentlige myndigheders hjemmesider fortsat kun understøtter RC4.

I øvrigt hvad angår Safari 5.1.9, så er dens foretrukne cipher faktisk TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=5.1....

Internet Explorer 6 derimod understøtter imponerende nok ikke en eneste sikker cipher - med mindre altså at man tæller 3DES 112-bit og RC4 128 bit med SHA som sikre:

https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=6&platfo...

Uffe Seerup

Internet Explorer 6 derimod understøtter imponerende nok ikke en eneste sikker cipher

Internet Explorer 6 er ikke længere supporteret. Den har været sat på udfasningslisten længe og i Danmark stod den i december 2013 for 0,017% (http://www.fdim.dk/Statistik/teknik/browserbarometer). Ingen bør tage hensyn til den browser mere.

Så hvor vil du hen med at den "imponerende nok ikke understøtter sikre ciphers (i 2014)"? Browseren er fra 2001!

Safari 5.X stod for 1,6% af trafikken - dvs næsten 100 gange mere end IE6.

Det giver mening stadig at tage hensyn til 1,6%. IE6 kan bare ignoreres.

Kim Bjørn Tiedemann

God artikel om et væsentligt emne - og fint med vinklingen på offentlige myndigheder som i mine øjne er særligt slemme til at være laaaangt bagud med TLS/SSL-sikkerheden.

Mange tak :-)

Apropos cipher-opsætning kunne det ikke være relevant at sætte spotlight på hvor mange offentlige hjemmesider der kun tillader brug af RC4-kryptering som Microsoft mig bekendt også fraråder? Sidst jeg tjekkede kunne man kun bruge RC4 på netsteder som borger.dk, skat.dk osv.

Det er en god ide - specielt må man sige at tastselv.skat.dk scorer dårligt. På SSLLabs får sitet et F (A-F) på grund af:

  • Support for SSL2
  • SHA-1 algoritme i certifikatet
  • Ingen support for TLS1.2
  • For næsten alle browsere benyttes TLS_RSA_WITH_RC4_128_MD5

Det er ret ringe, når man tænker på deres angrebsflade må tænkes at være ret stor.

Christian Nobel

Det er mærkeligt at Version2 ikke beskytter sine brugeres login med HTTPS.

Er det ikke et spørgsmål om at vælge sine slag med omhu?

Den eneste oplysning V2 har om mig er mit navn og min mailadresse (som kunne være en skraldespandskonto, kun til det formål), og så et password jeg har lavet, kun for V2 brug.

Jeg er helt enig i at man skal passe på personfølsomme oplysninger, men i det spil er V2 så inderligt ligegyldigt - men klart, hvis man skulle oplyse CPR nummer, adresse, "NemID" validering og hvad ved jeg, så var det en anden sag.

Herudover, så beskytter HTTPS vel ikke som så brugernes login, men sørger for kryptering af kommunikationen - den bagvedliggende database kan sagtens kompromitteres alligevel.

Peter Jensen

Sikkerhed og privatliv har ikke noget med udvalgte "slag" at gøre. Det er en farlig forsimplet tankegang.

Det opnåes kun gennem en kulturændring hvor dette fremover indtænkes i alt hvad man laver.

At en given beskyttelse ikke har nogen betydning for dig som enkeltperson, giver dig ikke ret til at fratage den fra andre, eller at fraskrive den en værdi for andre mennesker.

Hvis du kendte til hvordan folk generelt anvender email og passwords, så ville du også vide at de fleste anvender den samme email og password mange andre steder.

Log ind eller Opret konto for at kommentere