Even voorop: er is niets mis met https. Maar er is wel wat mis met de manier waarop het wordt ingezet, waardoor je soms gaat denken dat het misschien beter is dat er geen https wordt gebruikt, dan dat het gebrekkig wordt gebruikt. Dat laatste zorgt er immers voor dat gebruikers een vals gevoel van veiligheid krijgen, waar ze bij een http-site misschien beter zouden opletten.
(Los van die discussie of de meeste gebruikers überhaupt zien wanneer ze https gebruiken. Ik ga er, als eeuwige optimist die ik ben, vanuit dat dat wel zo is.) Laten we eerst even kijken wat er zoal verkeerd ging dit jaar.
Certificaten onterecht goedgekeurd
Eerst was er Apple's goto-fail, wat een programmeerfoutje was. Er was een regel 'goto fail' te veel toegevoegd aan een if-statement, waardoor de verificatie niet wordt uitgevoerd en elk certificaat als geldig wordt gezien. Dat betekent dat zelfs een al jaren ingetrokken en in 2009 bemachtigd Diginotar-certificaat genoeg is voor een geldige https-verbinding.
Een soortgelijke fout zat in GnuTLS, al sinds 2005 zelfs. Deze bug zorgde er ook voor dat certificaten onterecht als geldig worden gezien. De verantwoordelijke library is gebruikt in populaire serverdistributies als RHEL en Debian, waarmee deze misser ook een pijnlijk IT-incident was die een forse reeks patches voor Red Hat, Debian en Ubuntu opleverde - en natuurlijk een directe update voor GnuTLS zelf.
Kleine fout; grote gevolgen
Daarna volgde de grote: Heartbleed. Hierbij kon een TLS-feature om verbindingen open te houden worden misbruikt om serverinformatie op te halen, doordat OpenSSL de feature verkeerd had geïmplementeerd. Het probleem hierbij is dat OpenSSL in veel, veel producten is opgenomen en patchen een regelrechte nachtmerrie bleek voor IT'ers vanwege de vele haken en ogen. Dit gat gaat dan ook nog een lange staart krijgen.
Dan hebben we nog POODLE. Dat is een relatief eenvoudige aanvalsmethode op SSLv3. Dat is een protocolversie uit de jaren 90, die voor de onthulling van de bug nog erg veel werd gebruikt om sites zoveel mogelijk achterwaarts compatibel te houden. Het was geen probleem van Heartbleed-proporties. Veel sites trokken de ondersteuning in, maar belangrijker: browsers zorgden ervoor dat v3 niet meer werd ondersteund.
Reageren op fouten
Daar zit 'm meteen het goede nieuws: de reactie. Bugs zijn een onvermijdelijk gevolg van programmeren. Laat niemand je iets anders wijsmaken - zoals meerdere leveranciers bij mij hebben geprobeerd. De vraag is hoe je ermee omgaat. Apple fixte zijn bug snel, net als distro's die de GnuTLS-library gebruikten. Voor Heartbleed werd een gecoördineerde, hoewel bekritiseerde, patchactie in gang gezet en ook SSLv3 werd rap uitgefaseerd nadat bleek hoe brak dat inmiddels was geworden.
Dat lijkt me het allerbelangrijkste. Alle discussies die volgen zijn IT-varianten op een ramp die eigenlijk iedereen die erbij betrokken was wel zag aankomen en waar tóch opeens met een strak gezicht wordt gevraagd: hoe heeft dit kunnen gebeuren? Ja, goto-fails zouden moeten worden opgepikt in reviews en ja, een bug in de OpenSSL-implementatie van TLS-Heartbeat had veel en veel eerder opgepikt moeten worden. Veel ogen, maar niemand kijkt - dat argument.
Foutje mag best, maar niet zo groot
Natuurlijk moet er beter naar afgeleverde code wordt gekeken en er zijn zeker lessen te leren uit deze SSL-mislukkingen. Het lijkt me goed dat er af en toe incidenten zijn om ontwikkelaars, managers en het publiek met de neus op het feit te drukken dat code bugs kunnen, nee, zúllen bevatten. Maar dan komend jaar liever niet opnieuw met een fout met gigantische impact, zoals met OpenSSL. Dan liever een goto-failtje of twee in specifieke implementaties.
-
-
Er zijn nog geen reacties.Reageer
Preview