Den 3. marts hørte vi om “FREAK” – et nyligt opdaget angreb på SSL/TLS. Dette er blot det seneste af en lang række angreb, og vi husker vel alle endnu Heartbleed, POODLE og i øvrigt Apples underholdende GOTO-bommert. Vi har et problem, der næppe kan råbes højt nok om: sikkerhedsmekanismer, der ikke bliver vedligeholdt, ikke bliver reviewet godt nok og generelt er svære at forstå, så alvorlige bugs kan undgå offentlighedens opmærksomhed i årevis.
Jeg har overvejet, hvorfor det sker så ofte, og hvad vi kan gøre for at undgå det. Der er tre ting, jeg umiddelbart kan komme i tanke om, der står i vejen:
1. Manglende vedligeholdelse.
2. Dårlig læsbarhed og dermed en dårligere reviewproces.
3. Manglende forståelse.
Nummer 2 hænger sammen med et andet emne, jeg er meget interesseret i, nemlig kodekvalitet. Det er et emne, der ofte fører til irriterede suk eller verbale slagsmål, men ikke desto mindre er det væsentligt, og mange klogere mennesker end jeg har allerede sagt meget om det. Jeg vil bare gerne postulere, at en ekstra høj grad af kodekvalitet er tvingende nødvendig for at kunne have sikker software. Nummer 3 er ret åbenlys, men den skal med for en god ordens skyld; hvis du tror, du selv kan designe et sikkert system uden at sætte dig ind i best practices, tager du fejl.
I denne artikel vil jeg fokusere på nummer 1: den manglende vedligeholdelse.
Manglende vedligeholdelse
Vi benytter os ofte stadig af teknologier, som har kendte sikkerhedsproblemer (nogle er ret teoriske, andre mere praktiske). Eksempelvis baserer POODLE sig på et såkaldt “padding”-angreb på symmetrisk kryptering i CBC-mode uden ordentligt integritetscheck. For de uindviede er der her tale om et ikke specielt eksotisk angreb, der efterhånden har været kendt længe og forholdsvis nemt kan undgås. FREAK er, meget lig POODLE, et angreb, der udnytter, at vi stadig tillader brug af ældgammel teknologi, nemlig de såkaldte RSA-EXPORT keys, som ikke er længere end 512 bits.
I begge tilfælde er der tale om fejl i implementationen, der tillader brug af de gamle teknologier, men jeg kunne godt tænke mig at vide, hvorfor bevist usikre teknologier som for eksempel RSA-EXPORT keys ikke er fjernet helt for længst. Hvad laver de egentlig på en server i år 2015? Jeg er godt med på, at der er en masse ting, der skal spille sammen, og at vi derfor understøtter mange forskellige gamle versioner, men det er efter min mening blevet en undskyldning for sjusk og decideret skadelig praksis. Går den, så går den.
Kan jeg mon finde på andre eksempler? Jamen lad os da kigge i mine rodcertifikater på Windows. Her har jeg fundet:
Denne skønhed er et certifikat baseret på MD5 og en 1024-bit RSA-nøgle og udløber i 2018. MD5 har været i skammekrogen i årevis, og 1024-bit nøgler er på ingen måde tidssvarende, men dette certifikat er ikke desto mindre holdbart 3 år endnu. Mindre slemt står det til med de mange certifikater baseret på 2048-bit RSA med SHA1; de kan nok ikke lige brydes nu, men gælder det samme mon om 15 år? Jeg kunne godt have ønsket mig en kortere holdbarhedsperiode generelt.
Det er tvingende nødvendigt for alle, der arbejder med kryptografi, at følge bare lidt med i udviklingen. Vi kan ikke alle være kryptoeksperter, men heldigvis er der råd at finde. En lang række organisationer udgiver løbende råd og vejledning til valg af kryptomekanismer og nøglelængder. For eksempel har vi:
– ECRYPT II 2012
– ENISA
– NIST
– keylength.com (jeg har ikke fact-checket denne og foretrækker at gå direkte til kilden)
Jeg gør her opmærksom på, at der har været nogle kontroverser omkring NIST-standarderne (se for eksempel her eller her). Dem vil jeg hellere lade eksperterne tage stilling til, men det bør nævnes. ENISA-vejledningen fandt jeg nok mest informativ af de ovenstående.
Yderligere vil jeg nævne, at OWASP har meget fornuftigt at sige om websikkerhed, hvis man beskæftiger sig med den slags, og jeg vil på det kraftigste anbefale CERTs “secure coding guidelines” til udviklere, specielt hvis man sidder med C eller C++.
Jeg håber, at vi kan bruge det nylige FREAK-angreb som en undskyldning for at få opdateret vores viden, få ryddet op og strammet op. De har allerede det næste akronym klar.