Ny open source SSL-løsning klar efter Heartbleed-skandalen: OpenBSD-folk lancerer LibreSSL

Folkene bag styresystemet OpenBSD har lanceret en SSL-løsning, der kan afløse OpenSSL. Og det er dygtige folk, der står bag, vurderer open source-udvikler Poul-Henning Kamp.

Det katastrofale Heartbleed-hul i OpenSSL-protokollen, som blev brugt af alverdens webservere, er måske nok blevet lukket - men det er ikke holdbart at køre videre med OpenSSL. Derfor må der en helt ny og gennemsikret SSL-løsning til.

Sådan lyder rationalet bag et nyt open source-projekt, hvor holdet bag styresystemet OpenBSD har sat sig for at ’forke’ OpenSSL. Det sker ved at splitte hele OpenSSL-kodebasen ad og lade en ny, slankere og mere sikker version stige op af asken. Navnet på projektet er nu besluttet, nemlig LibreSSL.

Det fremgår af en bevidst utrolig grim hjemmeside, hvor OpenBSD-folkene kortfattet fortæller om projektet og beder om bidrag til at fortsætte. Foreløbig findes LibreSSL nemlig kun til OpenBSD, men med det rette finansielle fundament vil projektet fortsætte og blive kompatibelt med andre styresystemer også, lyder meldingen.

Læs også: Ny undersøgelse: 612 danske webservere har ikke lukket Heartbleed-hullet

Men om LibreSSL er løsningen på den nuværende tillidskrise til sikkerheden på internettet, er for tidligt at sige, mener Poul-Henning Kamp, open source-udvikler og dybt involveret i ’konkurrenten’ FreeBSD samt blogger på Version2.

»Jeg vil vente og se, hvad de har lavet, før jeg tager stilling. Jeg vil se koden først,« siger han til Version2.

Han understreger omvendt også, at OpenBSD-holdet er højt kvalificeret til at løse opgaven.

»Hvis der er nogen, der kan redde den kodebase, er det dem. De er bestemt kompetente, og OpenBSD har et antal gange før gjort noget, som fik stor betydning, med deres lidt kompromisløse holdning,« siger Poul-Henning Kamp.

I flere sammenhænge har han slået på tromme for, at OpenSSL må aflives fuldstændigt, fordi det skandaleramte open source-projekt er så kodemæssigt problematisk, at det ikke står til at redde.

De 300.000 linjers kode er et stort rod, som er dårligt dokumenteret, og koden rummer for eksempel 6.740 Goto-kommandoer, skriver Poul-Henning Kamp i et indlæg på fagmediet ACM Queue, og samme toner slår han an i et blogindlæg på Version2:

»Problemerne i OpenSSL er dybe og alvorlige, der er brug for at definere et helt nyt gennemtænkt API, og der er brug for at skrive koden om fra grunden, med falkeblik for sikkerhed i alle ender og kanter,« skriver Poul-Henning Kamp.

Læs også: Programmøren bag historisk sikkerhedshul taler ud om nytårsbrøler

Som med al anden kritisk kode er det store spørgsmål, om man stoler på udviklerne bag, og lige med OpenBSD-holdet er ’stoler’ et lidt svært ord at bruge, fortæller FreeBSD-udvikleren, der kalder OpenBSD-folk for mere politiske.

»OpenBSD-folkene har en højere kredibilitet end mange andre, og jeg tror på, at de ikke lægger bagdøre ind i koden. Men de kan også være nogle asociale røvhuller, og de kan også være en lille smule for politiske,« lyder hans karakteristik.

LibreSSL-projektet er under alle omstændigheder et skridt i den rigtige retning, vurderer Poul-Henning Kamp.

»De fjerner en masse crap, som i hvert fald ikke gavner noget, fra koden. Så det må blive inkrementelt bedre. Spørgsmålet er så, hvor meget bedre det bliver. Men det er godt, at der kommer fokus på OpenSSL-koden, og det er ikke noget dårligt crew til den opgave,« siger han.

Læs også blogindlæg: OpenSSL er død, længe leve LibreSSL

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Povl H. Pedersen

Der er også PolarSSL, som netop blev udviklet for at slippe fri af NSAs OpenSSL projekt. Det blev skrevet om fra bunden, og har et langt mindre footprint. At fortsætte med OpenSSL er tåbeligt. Start fra scratch / næsten scratch. Hvor svært kan det være. Det tager bare tid.

  • 1
  • 2
Martin Clausen

Ja, samt en masse andre implementeringer.

I forhold til PolarSSL, så fejler denne i andre sammenhænge - se fx "Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations".

Faktum er at der til stadighed findes fejl i de forskellige implementeringer. Derfor er review og test et kritisk element i udviklingsprocessen.

  • 1
  • 0
Helge Svendsen

Man skulle synes, det ville være lettere at starte med et lightweight alternativ i stedet for at forke OpenSSL.

Det er i hvert fald meget sjovere at sidde at tilføje funktionalitet, så det ville kunne nogenlunde hvad OpenSSL kan end at slette og refaktorere sig gennem 300K linjers kode ingen kan huske hvorfor er lavet mere.

Men respekt til OpenBSD holdet for at gøre noget ved det under alle omstændigheder.

  • 2
  • 1
Joe Sørensen

Man er normalt også ked af at lave store kode refaktureringer i andres projekter, da man let kommer til at break'e noget man ikke selv har mulighed for at teste. Derfor er OpenSSL blevet behandlet som en varm kartoffel.

Derfor mener jeg de gør det rigtige. De sletter alt, som de ikke ved hvad der. Hvis nogen savner det, så kan de reimplementerer det igen. De har jo OpenSSL koden.

De skriver det det til OpenBSD, men det vil kunne compile i alle Posix systemer. Hvis der er nogle optimerede features i Linux du vil have LibreSSL til at bruge, så send et patch. Hvis du vil have Windows support, så send et patch. Hvis du vil have VMS, Windows9X og OS/2 support, fint, send patches. Du kommer selvfølgelig selv til at vedligeholde de patches du sender. På den måde bliver det også klart hvem der har ansvaret for hvad. Og det kode som ingen har ansvar for, forsvinder.

Jeg har forstået at de også sletter support for protokoller og algoritmer, som ikke er sikrer. Fint, så er der det mindre at tage fejl af.

Når de er færdige, bliver det meget lettere at afgøre om der er fejl. Det kan godt være at HeartBleed rent kodemæssig var en ret lille fejl, men havde man gjort den fejl en et C program med en mere almindelig hukommelsesstyring, ville styresystemet enten have standset programmet eller det ville kun have sendt 00'er tilbage i stedet for data som der ikke bør være adgang til.

Et andet problem med OpenSSL er også at den general stoler for meget på indput og kan derfor bruges til at lave nogle lidt sjove certifikater med. Dvs at certifikat udsteder skal sikrer sig at indput giver mening før de sender det til OpenSSL. Og det har vist sig at det er de ikke for gode til.

  • 3
  • 1
Jesper S. Møller

Enig I at det er en fin idé med et rewrite, men burde man ikke vende processen om og starte med at udvikle testframework som ideelt dækker OpenSSL/GnuTLS/PolarSSL/? og skrive tests til alle de features, man gerne vil teste i TLS, DTLS og evt. SSL v2/3.

Nu har jeg ikke arbejdet med sikkerhedsprotokoller som sådan, men med stort set alle andre protokoller og ikke mindst sprog er man jo ikke 'Done' før man har en gentagelig (og gentaget) test med et dækkende testbatteri.

Både i tilfældet med Apples certifikatvalidering og med Heartbleed havde helt enkel basistest af forventede protokolovertrædelser gjort det indlysende at der var en fejl:
- "Når jeg handshaker med et certifikat, der ikke matcher på common name, forventer jeg fejlkode Xxx" (fanger Apples døde kode, hvis ikke en coverage-analyse gør)
- "If the payload_length of a received HeartbeatMessage is too large,
the received HeartbeatMessage MUST be discarded silently." ( <-- tekst fra RFC 6520 )
- "Generering af 'n' private nøgler via en PRNG skull give 'n' forskellige resultater, for en rimelig høj værdi af n" (hvis I husker den fra Debian)

Et stort testbatteri er en stor investering, men er langt vigtigere end blot at erstatte kode, man "ikke ved hvad er".

  • 2
  • 0
Jesper S. Møller

Jooh, men hvordan kan man sikre at en test kan fange alle mulige fejlkombinationer, med mindre systemet ar bygget til kun et lille antal funktioner.

Det er selvfølgelig korrekt at tests ikke kan sikre dig imod fejl, og hvis din kode eller tests er dårligt organiserede kan det være svært at skrive fokuserede tests på intern funktionalitet. Du kan heller ikke teste dig til bedre kvalitet i design eller kode, når det først er skrevet.

MEN! Du kan bruge dine tests som et indeks over den funktionalitet, der skal implementeres. Sikkerhedsområdet er jo rent generelt et spørgsmål om at implementere en række standarder. Disse standarder indeholder en række krav, som man kan skrive en række tests for, ligesom med alle andre typer af tekniske systemer.
I tilfældet Heartbleed ville man have sikret imod fejlen ved blot at checke imod spec'en om kravet var dækket af en test.
Kravmatrix, anyone?
En undskyldning om at systemet er for stort målt på funktionalitet er jo uacceptabel - hvis designet er for kompliceret at teste er det også for kompliceret at udvikle.

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