OpenBSD-ontwikkelaars maken OpenSSL-fork

De ontwikkelaars van het OpenBSD-besturingssysteem hebben een fork gemaakt van de code van het OpenSSL-project en zijn flink gaan schrappen in de code. Volgens de developers is na de Heartbleed-kwetsbaarheid gebleken dat de codebase van OpenSSL structureel onveilig is.

De fork van OpenSSL, een breed gebruikte opensource-ssl/tls-implementatie, is LibreSSL gaan heten. De developers stellen op een inderhaast ingerichte website dat zij druk bezig zijn om code te verwijderen uit de OpenSSL-implementatie. De LibreSSL-fork moet uiteindelijk zijn thuis vinden in OpenBSD, waarbij de ontwikkelaars verwachten dat de fork als eerste in OpenBSD 5.6 zal verschijnen.

Het Heartbleed-lek in de OpenSSL-programmeerbibliotheek is volgens veel softwareontwikkelaars mede het gevolg van onleesbare en complexe code, en slechte documentatie vanuit de OpenSSL-ontwikkelgemeenschap. De ontwikkelaars achter de LibreSSL-fork spreken dan ook over een 'zeer slechte codebase' en zeggen de code flink te gaan opschonen.

Theo de Raadt, oprichter van het OpenBSD-project, laat tegenover ZDNet weten dat er inmiddels al honderdduizend regels code zijn verwijderd, zoals overbodig geworden implementaties voor enkele antieke besturingssystemen als OS/2 en Netware. Daarnaast moet LibreSSL gaan voldoen aan de Posix-standaard waardoor het op vrijwel alle Unix-achtige besturingssystemen moet kunnen draaien. De developers staan overigens open voor donaties: pas als er voldoende geld is opgehaald zal het Comic Sans-font van de inderhaast ingerichte website worden vervangen door een ander lettertype.

Reacties (100)

Wie wil volgen wat er allemaal verwijderd wordt. Er is blijkbaar iemand die zich amuseert met dat op te volgen (niet van het OpenBSD team blijkbaar): http://opensslrampage.org/

LOL.., is toch wel even schrikken!!
Hulde aan het OpenBSD team.

Hulde vind ik eigenlijk een beetje te ver gaan. OpenSSL is een OPEN SOURCE framework, dus waarom doet BSD precies een fork? Waarom is men niet bezig de code van het OpenSSL framework zelf?

Nu moeten we straks beslissen of we OpenSSL of LibreSSL gaan gebruiken in combinatie met services.. Daarnaast als straks de volgende iteratie van de SSL of TLS specificatie uitkomt moeten die ook dubbel geimplementeerd worden. En er is geen enkele garantie dat hoewel de BSD developers nu goed werk doen, dat ook blijven doen.

Het initiatief op zich vind ik wel goed: Namelijk het reviewen van de OpenSSL code en bepaalde delen van de code te schrappen of te herschrijven, maar ik kan niet inzien waarom die fork nodig was. Het kan niet aan de license liggen want deze was al gebaseerd op de BSD license..

Waarom is men niet bezig de code van het OpenSSL framework zelf?

Omdat de aanpassingen die men nu maakt, zeer waarschijnlijk deels geweigert zullen worden door de OpenSSL beheerders.

Er worden namelijk nu 'niet essentiele' zaken verwijdert, maar de definitie daarvan zal ongetwijfeld verschillen per persoon.

Maar het is wel een goede zaak. Die OpenSSL broncode was ook een chaos. Het had een gebrek aan commentaar, en de namen van variabelen waren nu niet echt duidelijk (p = pointer, zijn developers nu echt zo lui dat meer dan 1 teken voor een variabele naam niet mag ). Dat is niet enkel cosmetisch, maar zorgt er voor dat een getallenteerde developer die ook nog eens van securtity wat af weet, desondanks veel moeite zal hebben om zich in te werken. Immers de code is niet zelf-leesbaar en er is geen commentaar.

Het is exact dat soort zaken wat HeartBleed bugs waarschijnlijker maakt, omdat aan de code zelf niet zichtbaar was dat men de ongeverifieerde lengte van de payload gebruikte, ipv de variabele die de lengte van de gealloceerde buffer bevat.

En voor iemand mij verkeerd begrijpt: nee dat heeft niets met open source te maken. Gewoon met slecht geschreven code die op een gegeven moment zo groot wordt, dat het bijna niet te doen is om terug te gaan. Vandaar dat de Heartbleed bug best nog wel eens positieve effecten kan hebben op lange termijn.

Je ziet nu dat talloze servers hun OpenSSL veries updaten en als neveneffect opeens beter ciphers ondersteunen dan voor de patch (zo ook Tweakers ).

Plus dat de Heatbleed een veel ergere designfout in OpeSSL bloodgelegd heeft. namelijk dat voor bepaalde onderdelen geen secure-malloc/free gebruikt werd maar een gewone. Juist die tweede bug maakte de Heartbleed zo gevaarlijk. Die tweede bug is in zekere zin veel erger, omdat het een design-fout was. Die was waarschijnlijk nooit gevonden zonder dit incident.

Caching provider Akamai had die tweede bug overigens al 2 jaar geleden gevonden, maar helaas was de uitvoering van hun patch onvolledig. Hetgeen eens temeer maar aangeeft dat zélfs als je bij OpenSSL het probleem ziet, de code structuur een fix moeilijk maakt.

[Reactie gewijzigd door Armin op 22 april 2014 20:46]

Hulde vind ik eigenlijk een beetje te ver gaan. OpenSSL is een OPEN SOURCE framework, dus waarom doet BSD precies een fork? Waarom is men niet bezig de code van het OpenSSL framework zelf?

Omdat ze anders niet de slag kunnen maken die ze nu maken, OpenSSL heeft te weinig mankracht om al die patches te controleren en te verwerken, daarnaast hebben hun een eigen richting gekozen ipv zich aan de POSIX standaard te houden, elke patch die niet in die richting past zullen ze weigeren wat ook geresulteerd zal hebben in een fork...

Nu moeten we straks beslissen of we OpenSSL of LibreSSL gaan gebruiken in combinatie met services.. Daarnaast als straks de volgende iteratie van de SSL of TLS specificatie uitkomt moeten die ook dubbel geimplementeerd worden. En er is geen enkele garantie dat hoewel de BSD developers nu goed werk doen, dat ook blijven doen.

Je hoeft geen keus te maken, maar je KAN hem maken als je dat wilt, OpenSSL blijft gewoon naast LibreSSL bestaan. Wel naar zo'n keus, ik heb ook liever dat ijsboeren alleen vanille ijs verkopen, nu moet ik straks beslissen of ik een bolletje vanille wil of chocolade...

Tevens weten we idd niet of de OpenBSD goed werk blijven doen, maar als we kijken naar OpenBSD en OpenSSH lijkt me dat wel aannemelijk...
Als we kijken naar het verleden is het wel duidelijk dat OpenSSL duidelijk zijn gebreken heeft, en de developers dus duidelijk GEEN goed werk gedaan hebben.

Het initiatief op zich vind ik wel goed: Namelijk het reviewen van de OpenSSL code en bepaalde delen van de code te schrappen of te herschrijven, maar ik kan niet inzien waarom die fork nodig was. Het kan niet aan de license liggen want deze was al gebaseerd op de BSD license..

Omdat ze hun patches niet door de openssl review procedure heen zullen kijgen.

Je hoeft geen keus te maken, maar je KAN hem maken als je dat wilt, OpenSSL blijft gewoon naast LibreSSL bestaan.

De bestaande OpenSSL library blijven gebruiken is OOK een keuze. De vergelijking met vanille en chocolade ijs gaat niet op, komt meer in de buurt van links of rechts draaiend gemaakt. Want OpenSSL en LibreSSL leveren hetzelfde, namelijk een SSL/TLS library en alleen de implementatie is anders, de uitwerking (smaak) is hetzelfde.

Omdat ze anders niet de slag kunnen maken die ze nu maken, OpenSSL heeft te weinig mankracht om al die patches te controleren en te verwerken, daarnaast hebben hun een eigen richting gekozen ipv zich aan de POSIX standaard te houden, elke patch die niet in die richting past zullen ze weigeren wat ook geresulteerd zal hebben in een fork...

OpenSSL maakt gebruik de GIT repository. Daar gebruikt development per definitie op een aparte branch welke later weer gemerged wordt en zolang de code blijft voldoen aan de unit- en regression tests zou ik niet zien waarom men een tree merge zou weigeren. Is dat al gebeurt of doet men (zoals jij nu) alvast die aanname?

Omdat ze hun patches niet door de openssl review procedure heen zullen kijgen.

Dat kan ik dus nergens uit opmaken. Niet uit de online archive van OpenSSL of de website van LibreSSL.

Maar zoals ik al aangaf juich ik het initiatief tot het verbeteren van de code van harte toe, maar ik betwijfel of een fork de juiste weg is. Er is een grote kans dat er een tweedeling ontstaat in de community en ik weet niet of dat wel zo goed als bij een onderwerp als security..

"De vergelijking met vanille en chocolade ijs gaat niet op, komt meer in de buurt van links of rechts draaiend gemaakt. "

Ik zie het meer als de lijst van ingredienten.
OpenSSL zit barstensvol met hulpstoffen en hulpstoffen om de hulpstoffen te verhullen en hulpstoffen die eigenlijk nergens voor dienen. En LibreSSL brengt het (zo te zien) weer terug naar een robuust en 'eerlijk' eisje.

Maar zoals ik al aangaf juich ik het initiatief tot het verbeteren van de code van harte toe, maar ik betwijfel of een fork de juiste weg is. Er is een grote kans dat er een tweedeling ontstaat in de community en ik weet niet of dat wel zo goed als bij een onderwerp als security..

Ja, want het is veel beter dat wanneer er een lek is dat die globaal iedereen nekt ? Er is niks met verschillende implementaties, die zijn er trouwens al (gnutls, nss, schannel, openssl, ...). Hoe meer hoe beter zeg ik. Je spreidt zo je risico.

Het probleem was dat de OpenSSL developers opzettelijk ervoor kozen om eigen "veilige" functies te gebruiken. Zo'n zogenaamd veilige functie (malloc) bleek onveiliger te zijn dan de standaard malloc van OpenBSD.

Met die OpenBSD malloc functie was HeartBleed een DDOS geweest - vervelend, maar geen veiligheidsprobleem. OpenSSL zou simpelweg crashen op de lengte-bug, in plaats van vertrouwelijke data te retourneren.

Het was niet alleen de Malloc functie. De OpenBSD malloc wist idd wel bij allocatie 't geheugen en die van OpenSSL niet. Dat is 't aller grootste probleem.

Maar volgens de specificatie hoor je te controleren op onzinnige heartbeat requests en die stilzwijgend af te wijzen. Als de aangegeven lengte (in de header, 64K max) afwijkt van de lengte van wat je ontvangen hebt is 't onzinnig en moet dus genegeerd worden.

Het echte probleem is dat in hun huidige versie (met OpenBSD MAlloc) je een grotere packet kan uitlokken door een kleine te sturen. Een Amplyfied DDoS dus eigenlijk. Misbruik van dat soort lekken gaat de komende jaren groeien denk ik.

Zo'n klein foutje in de implementatie van 1 specifieke response is geen aanleiding om te forken. Uiteraard is dat de echte bug, maar dat zegt niets over de mentaliteit. Het malloc() probleem zegt wel iets over mentaliteit, namelijk dat het OpenSSL team niet gelooft in defense in depth

Beschikbaarheid is een van de pijlers (BIV) van informatiebeveiliging; het ontnemen van beschikbaarheid dmv een DDoS is weldegelijk een beveiligingsprobleem. Je kunt er wellicht niet een netwerk mee binnendringen, maar niet alle beveiligingsissues kun je gebruiken om in te breken.

Maar dan was de bug misschien wel al eerder boven water gekomen. Nu heeft er jaren lang niemand iets gemerkt. Als de boel steeds platgegaan was, was het debuggen direct begonnen.

OpenSSL is een OPEN SOURCE framework, dus waarom doet BSD precies een fork?

• Omdat het kan, en omdat forken de enige manier is om zonder ellenlange discussies onenigheden tussen developers onderling op te lossen.
• Om te zorgen dat de controle van een belangrijk project als OpenSSL komt te liggen bij mensen met een (bewezen!) verantwoordelijkheidsgevoel m.b.t. security, en niet blijft liggen bij het clubje wat er nu duidelijk een puinhoop van heeft gemaakt,
• Omdat de BSD license toestaat dat de code echt 100% vrij gebruikt kan worden, zonder dat de gebruiker viraal verplicht wordt om evt. aangepaste source-code weer terug te geven aan de open-source community. Dit is erg belangrijk voor ondersteuning in proprietary software, zoals bijv. de Windows Kernel, etc. Deze kunnen de 'reguliere' OpenSSL code nu niet gebruiken vanwege de meer beperkte huidige licensing.

[Reactie gewijzigd door tofus op 22 april 2014 17:10]

Omdat de BSD license toestaat dat de code echt 100% vrij gebruikt kan worden, zonder dat de gebruiker viraal verplicht wordt om evt. aangepaste source-code weer terug te geven aan de open-source community. Dit is erg belangrijk voor ondersteuning in proprietary software, zoals bijv. de Windows Kernel, etc. Deze kunnen de 'reguliere' OpenSSL code nu niet gebruiken vanwege de meer beperkte huidige licensing.

Ehm, je realiseert je dat de licentie van een project niet kan veranderen door te forken?

Bovendien is de OpenSSL license praktisch een BSD-style licentie, welke het gebruik in closed al toestaat. Je virale verplichting-opmerking slaat dus nergens op

Windows heeft overigens zijn eigen SSL implementatie genaamd Schannel, dus die zullen niet snel een open source SSL library willen opnemen.


Wat ik me vooral afvraag is waarom ze hier energie in willen steken. Als OpenSSL zo slecht is, werk dan aan één van de andere SSL-libraries zoals gnutls of polarssl...

[Reactie gewijzigd door deadinspace op 22 april 2014 20:54]

Ik vermoed dat dit o.a. komt omdat OpenSSL als doelstelling heeft: crypto voor iedereen en de fork genoegen neemt met OpenBSD en de rest als het lukt. Vanwege het eerste deel is de code vrij complex geworden. Streep dit om een code-review mogelijk te maken en je houd iets over wat vrijwel niet te bereiken is op de huidige codebase zonder nog onleesbarder te worden.
Ervaring leert wel dat OpenBSD varianten van bibliotheken vrij snel vrij populair worden en zeg nu zelf: hoeveel internet facing Novell en OS2 servers heb je nog? Geen mag ik hopen.

"OpenSSL is een OPEN SOURCE framework, "

Ja, en die community heeft er een zooitje van gemaakt, toch?. Het bsd team heeft veel opmerkingen over de kwaliteit van de code. En de openSSL community gaat niet even opzij voor andere devs, denk ik. Die hebben hun eigen ideeen over de implemetatie. Dan is het zinnig om te forken.

[Reactie gewijzigd door koelpasta op 23 april 2014 08:36]

"Hulde vind ik eigenlijk een beetje te ver gaan. OpenSSL is een OPEN SOURCE framework, dus waarom doet BSD precies een fork?"

Ik doelde eigenlijk meer op het feit dat ze die code gewoon aanpakken. En door te forken hoeven ze niet om te gaan met de heersende politiek binnen zo'n langlopend project. Ze kunnen gelijk beginnen te snoeien zonder dat allerlei mensen verontwaardigd raken, etc..

Oh, man. Die code.
Zelfs een beginnend programmeur is niet zó slecht.

Wat is er dan specifiek zo slecht aan, dat een beginnend programmeur het beter zou kunnen? Het is code met historie, veel delen zijn geschreven om zo goed mogelijk multi-platform te zijn, om problemen tussen verschillende compilers en platformen te overbruggen. Dat dat heden ten dagen niet meer relevant is maakt de code niet slecht, hoogstens aardig gedateerd.

Ja, en er zullen ook wel de nodige bugs inzitten (zoals gebleken is met heartbleed), maar (helaas) zitten er veel bugs in alle code. Vanwege het bovenstaande is deze code hier wellicht wat vatbaarder voor, omdat de code veel dingen uit handen neemt van de compiler die dat (tegenwoordig in ieder geval) eigenlijk veel beter kan, en bovendien continu gemoderniseerd wordt.

[Reactie gewijzigd door MadEgg op 22 april 2014 17:29]

ehm

strncpy(dest, src, strlen(src));

doet een beginner nooit. Die gebruikt óf strcpy, of strncpy zoals hij wél bedoeld is.

En zo zijn er nog een hele hoop.

Een beginner weet niet eens van het bestaan van strncopy af, waarschijnlijk.

Verder wel een leuk voorbeeld, maar de gehele code base geeft niet direct de indruk van een beginner. Er worden vele complexe functionaliteiten gebruikt waar een beginner zich echt niet aan zal branden. Ik vind het statement dat zelfs een beginner niet zó slecht is dus wel aardig overtrokken. Er is ruimte voor verbetering, dat blijkt, maar ik wil nog wel eens een beginner zien die dergelijke code kan begrijpen, of fouten kan spotten die jij hier nu aangeeft.

Hoe oud zou deze link zijn: http://www.courtesan.com/todd/papers/strlcpy.html ?

Geef je op om mee te helpen aan die code zou ik zeggen. Eens zien of ze je accepteren

Oh, man. Die code.
Zelfs een beginnend programmeur is niet zó slecht.

Ja en als je bedenkt dat het halve internet van dit soort brouwsels aan elkaar hangt slaat de schrik je om het hart. Veel OpenSource is amper door andere mensen bekeken dan door de maker(s) laat staan dat er een gedegen risico analyse op los is gelaten.

Het probleem met dit soort projecten is vaak dat ze al heel wat jaren meegaan. Het OpenSSL project is al bezig sinds 1998 en de kans is groot dat de basis van de code in al die jaren nooit is herschreven (gegeven dat we pas recent een 1.0 hebben gekregen). Als je dan ook nog je backwards compatibeliteit wenst te behouden krijg je dus zeer complexe, moeilijke en soms onveilige code. X11 worstelt met hetzelfde probleem (maar heeft een codebase die afstamt van eind jaren 80!). Het is dus zeker niet slecht dat er nu iemand naar kijkt om alles eens op te ruimen, hoewel ik me afvraag of ze niet beter van 0 waren herbegonnen.

Ik ben benieuwd hoe deze fork zich gaat verhouden tegen MatrixSSL of PolarSSL

Sowieso zijn MatrixSSL en PolarSSL al GPL (al dan niet dual-licensed), LibreSSL is momenteel grotendeels 6-clause OpenSSL licensed (redelijk in de vorm van 4-clause BSDL met additionele vergelijkbare clauses) en waarschijnlijk wat 2-clause BSDL, dus dat kan al veel verschil voor bepaalde groepen uitmaken.

Technisch, sja, als het van dezelfde standaard is als bijvoorbeeld OpenSSH, dan zit dat wel goed. Aangezien code vanuit OpenBSD snel gedeeld wordt door zowel FreeBSD als NetBSD krijg je nog veel meer oogballen op die code. Netto denk ik dat die bibliotheek er onwijs op vooruit zal gaan t.o.v. OpenSSL. Maar goed, dan is het nog steeds vrijwilligerswerk (met wat corporate backing) tegenover bedrijven die het direct vanuit commercieel belang werk in steken.

Vanuit commercieel belang wordt dus beter werk afgeleverd denk je?
Ik denk dat juist die vrijwilligers gedreven zijn om zo'n goed mogelijk product te ontwikkelen. Je werkt tenslotte niet zomaar vrijwillig aan zo'n project.

Ja van elke natie gaat er iemand aan dat project meehelpen hoor.

Als je stevig betaalt heb je altijd iets beters, maar niemand is bereid om die securityprijs te betalen, want da's vrij prijzig. Je hele hardware infrastructuur dient dan ook omgegooid te worden.

Je moet je over open source geen illusies maken als het gaat om de security.

Op elk ander terrein als 't gaat om open source, dan kunnen we elkaar vinden denk ik

Als je stevig betaalt heb je altijd iets beters

Oh ja? Hoeveel security exploits bestaan er voor windows? en hoelang duurd het voordat het gepatched word?

Zet dat eens tegenover de hoeveelheid exploits voor OpenBSD en hoelang hun er over doen om het te fixen...

Je moet je over open source betaalde software geen illusies maken als het gaat om de security.

Plus bij opensource kan je altijd een audit doen op de broncode, ipv een binairy blob met wazige errors...

Op closed source kan dat ook, als de auditor maar toegang heeft tot de source.

Sleutelwoord is altijd, en voor de windows kernel kan je dat als gewone sterveling vergeten. Voor de linux kernel, of belangrijke libraries, duik ik gewoon de code in als ik een probleem tegenkom, terwijl dat voor Windows geen mogelijkheid is.

En stel dat je een closed source pakket hebt dat SSL gebruikt, hoe weet je dan of het OpenSSL is, en als dat zo is, hoe haalbje de kwetsbaarheid weg? Bij OSS download je de code en nieuwe library, en compileren maar. Succes daarmee voor closed source...

Voor jullie zelfgenoegzaamheid over open source onrealistische vormen aanneemt, laten we even de feiten bekijken:

Ondanks alle openheid en dat iedereen, altijd de broncode heeft kunnen bekijken, heeft er 2 jaar lang een kritieke vulnerability in OpenSSL gezeten, waardoor de communicatie met honderden, duizenden sites effectief niet beveiligd was.

Kortom, leuk dat het kan, open source beveiligingsproblemen oplossen, maar als niemand een probleem ziet, ben je geen haar beter af dan met closed source.

Sleutelwoord is altijd, en voor de windows kernel kan je dat als gewone sterveling vergeten.

Een gewone sterveling weet niet wat een kernel is, of een library, of code, en zal al helemaal niet in staat zijn om 'er in te duiken', een probleem te spotten of dit op te lossen. Je argument snijdt weinig hout. Oh, en al zou je in staat zijn om een probleem te vinden en op te lossen in de Windows-kernel of een Windows-component; je hebt er niks aan, want je kunt je gefixte componenten niet ondertekenen (godzijdank), dus zul je ze ook nooit kunnen gebruiken.

Hoezo kan ik dat niet signen? De meeste ontwikkeling aan open source wordt gedaan door betaalde medewerkers voor een commercieel bedrijf, Tomtom maakt bijvoorbeeld veel gebruik van open source libraries. Dus als ik ergens werk kan ik met de sleutel van die werkgever de library signen. Kernel wordt lastiger ja

Dit kritieke lek zat er wel 2 jaar in, maar was in een paar dagen na bekendmaking verholpen. Wat dat betreft heeft open source een betere track record dan closed source: veel snellere fixes.

[Reactie gewijzigd door MBV op 23 april 2014 08:28]

Hoezo kan ik dat niet signen?

Omdat ik het had over Windows-componenten. Niet third party-componenten die ergens in System32 zijn gedumpt, maar door Microsoft ontwikkelde componenten, zoals SChannel.

Neuh, niet noodzakelijkerwijs, maar ik kan me wel voorstellen dat validatie en certificering makkelijker binnen handbereik liggen.

vrijwilliger: Gaat door als hij zin heeft. En doet dit voor zijn lol.

Een prof doet dit van 9-5 en doet het voor zijn kost (en soms ook voor zijn lol)

Veel van die vrijwilligers van BSD projecten hebben als baan of bijbaan Audits doen op code voor bedrijven En zijn niet bepaald kleine namen daarin. Dit is code die vaak jaren oud is en multi-platform. Toen waren er dingen nog niet bekend/mogelijk

Ik hoop eigenlijk alleen maar dat het zorgt voor meer exposure voor die alternatieven, OpenSSL is te groot/bekend en word daarmee al snel een 'single point of failure' zoals recent gebleken is. Als het zo was geweest dat er meer alternatieven gebruikt werden zou een stuk beter uit hebben kunnen vallen.

O.a. de nederlandse overheid maakt gebruik van openvpn van fox-it.
https://www.fox-it.com/nl...kt-voor-overheidsgebruik/

Hierin is PolarSSL in verwerkt. Echter ook PolarSSL kent zijn problemen met remote exploidts etc.
https://polarssl.org/tech-updates/security-advisories

Wat ik hiermee wil zeggen, is dat een alternatieven niet altijd beter is.

Dat is niet waar ik op doelde, natuurlijk zit er in ieder zo'n library een aantal bugs en ze zullen nooit waterdicht zijn. Maar het hebben van verschillende libs zorgt er voor dat een specieke bug een kleinere impact heeft, eg. de bugs van OpenSSL zijn niet op PolarSSL van toepassing en visa-versa.

Daar heb je wel gelijk in. En het geld niet alleen voor openSSL.
Overigens zijn in veel opensource projecten openssl niet zo 1 2 3 te vervangen voor een alternatief.

Neem mod_ssl, een veel gebruikte module binnen apache, welke alleen werkt met openssl. Wil je dit vervangen zal je naar nginx moeten overstappen. Wat het voor de meeste beheerders weer lastiger maakt.

Het zou helpen als deze alternatieve API compatible zouden zijn met openSSL.

Probleem is dan weer wel dat enorm veel werk in veelvoud zal gebeuren, tijd die beter aan 1 enkel project kan besteed worden imho. Wanneer een project mismanaged word of wanneer je andere doelen stelt kan een fork nuttig zijn, maar niet gewoon om te gaan concureren.

Ik hoop dan ook dat OpenSSL zelf dit project ook zal steunen om op termijn terug naar 1 standaard project te komen (ongeacht welke naam het kind meekrijgt).

Ik denk persoonlijk dat het een grotere kans van slagen heeft omdat de BSD groep er achter staat, wat bekend staat om degelijk code

Dus op je systeem kan heel simpel die ene file geswapt worden waarna je dus afhankelijk bent van de nieuwe file hoe goed of slecht dat wel niet je encryptie is

Ik heb zo'n flauw vermoeden dat de authenticiteit van die file weldegelijk zal worden geverifieerd (signing). Je kan dus niet zomaar lopen swappen.

En je kan er al helemaal niet zomaar een 'andere encryptie' induwen; 2 apparaten die tegen elkaar praten maar elkaar niet begrijpen, daar ben je weinig mee.

[Reactie gewijzigd door Slonzo op 22 april 2014 14:52]

Dit gaat gewoon werkelijk nergens over... Hoeveel bugs gaan er wel niet geïntroduceerd worden door delen van OpenSSL te herschrijven? Begin dan gelijk van scratch.

Door vanaf scratch te beginnen introduceer je waarschijnlijk nog veel meer bugs.

Precies Lees vooral Things You Should Never Do, Part I by Joel Spolsky
http://www.joelonsoftware.com/articles/fog0000000069.html

[Reactie gewijzigd door 0TT0 op 22 april 2014 14:29]

Joel's artikel wordt echt te pas en te onpas aangehaald.

Het heeft totaal geen plaats wanneer je het hebt over OpenSSL: een 'tig jaar oude codebase doorzeeft met oude, niet langer relevante implementatie-details, die niet gebruik maakt van security-hardened designs en die eigenlijk geen eigen business logica codeert (het is een implementatie van een externe, goed gedefinieerde standaard).

En waarom heeft het dan geen plaats?

Joel zegt nergens dat je niet kan refactoren. Grondig refactoren zelfs. Maar hele brokken code weggooien zonder te kijken wat het is, hoe het in elkaar zit en of het misschien wel rekening houdt met potentiele exploits waar je zelf niet aan gedacht had? Erg onverstandig.

Ja, er is een standaard. De beveiliging treedt voornamelijk op wanneer een andere (kwaadwillende) partij zich niet volledig aan de standaard houdt. Het is dus belangrijk om heel goed door te hebben op welke plaatsen die kan gebeuren en hoe je daarmee omgaat. OpenSSL deed dat mbt de Heartbleed bug duidelijk niet goed, maar hoeveel andere bugs zijn in OpenSSL opgelost die je opnieuw introduceert door 'from scratch' te beginnen?

Door grondig te refactoren, zoals de mannen van OpenBSD nu aan het doen zijn, krijg je een veel beter eindresultaat: het goede van nieuwe inzichten en nieuwe stukken code met nieuwe veiligheidsprincipes schrijven maar ook het goede van bestaande, langdurig geteste code waarin de nodige exploits en bugs al zijn opgelost.

Daar heb ik mijn twijfels bij. Als de codebase van OpenSSL zo verschrikkelijk is als ze claimen weet je gewoon niet waarom bepaalde dingen zijn zoals ze zijn - straks introduceer je nog verschillende timing attacks omdat je een 'for' lusje leesbaarder hebt geschreven.

De openBSD mannen (en vrouwen) weten over 't algemeen wel waar ze mee bezig zijn op vlak van security.

En leesbare (of leesbaardere) code is ALTIJD een goeie zaak. Je kan dan wel een bug introduceren bij het refactoren van de code, maar je zal hem minstens 20x sneller terugvinden dan wanneer je een nieuwe bug introduceert in een hoopje spaghetticode.

Dat hangt van de programmeurs af, en ik neem vrolijk aan dat het verminderen van de codebase een hoop bugs om zeep helpt. Verder heeft BSD een focus op security, en dat lijkt me een uitstekende instelling voor een protocol als SSH, dat immers veilige verbindingen beweert te leveren.

Aan de andere kant zijn er ook patches geintegreerd voor bijvoorbeeld simpele null-ptr checks die al 2 jaar stonden te wachten in de OpenSSL bugtracker. Ik verwacht dat dit uiteindelijk een goede vooruitgang is.

Ik ben blij dat dit initiatief door ze ondernomen word, de commit messages die ze achter laten tijdens dit werk zijn zowel hilarisch als schrikbarend.

Yep... In de 40 uur hebben ze echt veel zooi opgeruimd. Alle "KNF" maken de code meer leesbaar, veel code wijzigingen om de zooi beter leesbaar te maken, en flink wat zooi verwijderd waarbij de malloc (memory allocation, dit was de basis van de heartbleed bug) de basis vormde voor een memory leak.

Dat is maar een halve waarheid, de oorzaak van de die bug in een buffer-overflow. Dat werd enorm verergert omdat OpenSSL niet de systeem malloc gebruikte maar hun eigen memory allocator. Die allocator clearde het geheugen niet, recyclede allocaties en had geen guard-pages, dingen die je van een os malloc (mits zo geconfigureerd) wel gewoon kunt verwachten.

Had het zelf tijdens de Heartbleed hype haussee ook al eens gemeld, maar kan me herinneren dat er toen een paar mensen waren die claimden dat het echt niet zo erg gesteld was met die custom memory allocator hoor, en dat de hele opzet van de OpenSSL codebase echt niet zo'n groot probleem was.

Hoop dat die personen met de beschikbaarheid van sites als http://opensslrampage.org nu mooi met hun neus op de feiten worden gedrukt. Ja; het is dus echt een complete pleurisbende.

Leuk dat openssl opgeruimt wordt en waarschijnlijk een beter product gaat worden. Maar de website is flauw.
Comic sans gebruiken om geld binnen te trekken en een link naar een youtube filmpje ipv van naar openssl.

/edit
Eigelijk is deze media aandacht voor LibreSSL / openBSD misschien hun redding. Ergens in januarie konde ze niet eens hun energie rekening betalen.

http://www.phoronix.com/s...page=news_item&px=MTU3MjE

Ik heb er problemen mee, hoe openBSD nu openSSL aan de schandpaal nagelt.

[Reactie gewijzigd door wica op 23 april 2014 04:49]

Flauw? Ik vind hem epic.
Ze gooien een van de meest schrale websites ooit in de lucht en zetten er doodleuk bij No we don't want help making web pages, thank you.
En die comic sans is een geniale zet om geld binnen te harken, want het doet gewoon pijn aan je ogen!

Das oude hackers humor. De meeste van bsd zijn niet echt jong meer. Maar besef wel, oude mannen zijn wijze mannen. Ik denk dat ze meer en beter programmeren dan menig andere hacker van 22 jaar (sterker nog sommige worden zelfs gevraagd voor audits)

Dit zijn mensen die die enorm kunnen bughunten binnen een kleine korte periode. Alleen ze zijn niet bepaald groot. Daarom willen ze ook van scratch beginnen bijna en de boel forken om snel en effectief een beter alternatief te bieden. Ze doen dit vaak voor hun lol en publiceren meer om zich zelf een doel te stellen dan om aanzien te krijgen.

Wat betreft de opzet van die site: Typisch humor en prioriteit. Hun doel is een probleem oplossen, niet een site maken die er zo netjes gelinkt uitziet dat er een heleboel tijd is ingestoken.

Hier niet, heb dan gelukkig ook een OS dat geen Comic Sans aan boord heeft

Onderin de pagina staat het volgende: "This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags"

Ik denk dat er snel een betere website zal zijn. Slimme zet van het OpenBSD-project om dit te doen...ik verwacht dat na de Heartbleed-heisa er wel enkele grote cheques van grote internetbedrijven en financiële instellingen in de collectebus van OpenBSD zullen belanden... Mooi staaltje marketing met een afschuwelijke website

Had er nog een <marquee> op gestaan ik had gedoneerd

On-topic:
Mooi dat er een nieuwe vrij SSL project uit de doeken gedaan wordt al vraag ik mij af of ze niet beter from scratch begonnen waren. Het lijkt mij, zeker voor security, toch wat raar om iets te gaan snoeien en daarop te bouwen.

SSL implementeren met alle nukken aan bestaande client-side implementaties en minor versies van de verschillende SSL/TLS protocollen en compatibiliteit is echt een drama. Hard snoeien in de bestaande code zodat alleen 'moderne' ondersteuning overblijft, beperkt tegelijkertijd de veiligheidsrisico's en garandeert toch de beste 'compatibiliteit' met bestaande systemen binnen afzienbare tijd.

Je kan het een 'zwakte bod' noemen, maar ik denk dat het het beste van beide werelden is. De flink gekortwiekte code refactoren en daarna tot in detail auditen is efficienter dan van scratch opnieuw beginnen en mogelijk nog veiliger ook, daar kinderziektes/beginnersfouten voorkomen worden.

Zonder de kwalitetit van de code te kennen, zal het vast wel niet zo slecht zijn als de meesten denken. Bovendien kun je heel goed bestaande code verbeteren. De beste methode is code reviews en daarnaast kunnen de verschillende quality tools ook helpen.

Zonder de kwalitetit van de code te kennen, zal het vast wel niet zo slecht zijn als de meesten denken. Bovendien kun je heel goed bestaande code verbeteren. De beste methode is code reviews en daarnaast kunnen de verschillende quality tools ook helpen.

Dat helpt echt maar tot op beperkte hoogte. Zoals onstabiele isotopen een 'critical mass' kennen, kennen codebases van redelijke grootte een 'critical mess', van waaraf wat je ook doet; het eigenlijk alleen maar erger wordt en niet meer te herstellen valt.

Het verschilt van project tot project waar die grens precies ligt, maar je doet er altijd goed aan de overweging te maken of greenfielding de moeite waard is; zeker als je vanaf een bestaande goed geschreven standaard een implementatie maakt en niet eerst feature extraction op een oude moloch van een codebase hoeft te maken.

[Reactie gewijzigd door R4gnax op 22 april 2014 21:47]

Het probleem met openSSL is dat die tools buitenspel worden gezet door hun eigen geheugenmanagement. Als je vervolgens dergelijke tools gebruikt heb je 2 problemen:
1. Bugs worden niet gevonden
2. Bewust gemaakte fouten worden wel gevonden

Ik gok dat veel mensen de problemen met Debian nog vers in het geheugen hebben zitten... iets met value is used uninitialized -> fix -> random numbers zijn ineens niet meer random.

Comic sans en blink tags zie je toch al jaren niet meer?

Zeker als je een moderne browser als IE 11 gebruikt. Heb je geen last van die blink-onzin.

(Sorry kon het niet laten )

Ik vind Comic-Sans het leukste lettertype, niks mis mee. Sterker nog, hier is voor het eerst dat ik iets negatiefs over lees.

http://www.comicsanscriminal.com/

Idd, Comic Sans is een fun letter type. En in die hoek moet het ook blijven. Maar blijkbaar nemen de LibreSSL snoeiers, het niet zo serieus.

Ik heb echt het idee of er een ontwikkelaar van 40+ aan de website heeft gewerkt,

Ik neem aan dat je zelf nog geen 40+ bent dan? Zou je kunnen beargumenteren waarom je denkt dat je zelf opeens slechte code gaat produceren als je de 40 bent gepasseerd?

En als je het voor jezelf niet kan, waarom zou het voor iemand anders wel opgaan dan?

...volgens mij loop je dus ook maar wat uit je duim te zuigen. Zoals het een onervaren jonkie betaamt, zou ik bijna zeggen!

Om dat de tag, <blink> uit de tijd van netscape stampt heel lang geleden. Terwijl de meeste moderne browsers deze tag allang (of nog nooit) ondersteunen. De meeste mensen die deze tag nog kennen zullen ergens boven de 30 zijn.

Huh. Ik ben nu 22, en ik heb de periode van <marquee>- en <blink>-misbruik nog volledig meegemaakt, gezien ik rond ~10 jaar oud begon met HTML. Het lijkt me niet dat ik daarmee de enige ben... 30+ lijkt me enigszins overschat.

Vast niet de enige nee. Statistisch gezien, dan. Maar uitzonderingen maken niet de regel, helaas.

Volgens mij had Diamondo25 het over de kwaliteit van de broncode in het geheel, niet het specifieke gebruik van de <blink>-tag.

Ik vroeg mij dan ook af wat dan precies het verband tussen leeftijd en code-kwaliteit was, waarop hij zijn uitspraak basseerde.

PS: Ik ben zelf (nog) geen 40+, overigens

De code zit er top uit, voor de tijd dat de blink tag gebruikt werd.
Nee, jij bent geen 40+ maar wel 30+

Inderdaad nette recht toe recht aan code zoals je het met de hand snel in elkaar kan zetten. Wel leuk om weer eens een "classic" pagina te zien :-)

Ik vermoed dat Diamondo25 een van deze hipsters is die de ontwikkelaar probeert te irriteren. Het doel is volgens mij dan ook al bereikt. Sinds hij nu aangeeft dat hij overweegt te doneren:)

Zelf vind ik het wel een goeie grap eigenlijk.

Tijd om eens gebruik te maken van formele verificatietools. Een hoop werk, maar op een project als dit is dat zeker geen overbodige luxe.

Dit gaat zo vol gaten komen te zitten - vooral de code die de daadwerkelijk encryptie verzorgen gaat - dat je je geen illusies moet maken

Als je zegt: "het is veiliger, want van 100k gaten hebben we d'r nog maar 10k over", hoeveel is zo'n statement waard?

Het grootste deel van die 100k lines die verwijderd zijn, zijn "backend" engines die OpenSSL kon gebruiken om te interfacen met PRNGs of hardware RNGs om zo extra "entropy" toe te voegen. Het nadeel daarvan is, dat niemand die verschillende configuraties kan testen of verifieren.

Verder is er een hoop VMS code verwijderd (evenals andere platformen) en zijn er een berg "wrapper" functies voor syscalls verwijdert omdat ze simpelweg niet meer relevant zijn sinds 10 jaar (ze zijn gestandaardiseerd in onder ander POSIX).

[Reactie gewijzigd door PrisonerOfPain op 22 april 2014 20:27]

Ja, voeg entropy toe door je private keys of digests door de RNG te gooien.
Nee, echt random, zo'n key.

edit:
Om over het beveiligingsrisico maar te zwijgen...

[Reactie gewijzigd door halofreak1990 op 22 april 2014 15:32]

Of door tijd bij je random numbers op te tellen

Slim gedaan. Nu móéten we wel doneren: "This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags"

Maar goed initiatief zou ik denken. Ik ben benieuwd of het zichzelf weet te bewijzen.

[Reactie gewijzigd door Bio op 22 april 2014 14:05]

De developers staan overigens open voor donaties: pas als er voldoende geld is opgehaald zal het Comic Sans-font van de inderhaast ingerichte website worden vervangen door een ander lettertype.

Haha leuke touch, interessant om te zien hoe Comic Sans de laatste maanden weer vanuit allerlei kanten belachelijk word gemaakt, de 'sociale internetgebruikers' hebben wat ontdekt hoor

In ieder geval, redelijk schokkend om te lezen dit verhaal, ik had toch altijd het idee dat OpenSSL enorm geoptimaliseerd was, en daarom zo wijd verspreid word gebruikt? jammer om te horen dat dat niet het geval is, nou heb ik alleen nog maar meer vraagtekens bij OpenSSL.

Wel goed om te zien dat er dus ook serieus gekeken word naar oplossingen, en niet alleen word gehoopt dat halfbakken patches van OpenSSL de boel kunnen repareren.

tja, achteraf commentaar geven over code dat al jaren op de markt is, is wel heel makkelijk..
En echt boosten over 'oh we hebben al zoveel regels code verwijderd' terwijl dat dus voor een groot deel te danken is aan het dumpen van OSsen die zij niet meer interessant vinden..

onleesbare en complexe code, en slechte documentatie vanuit de OpenSSL-ontwikkelgemeenschap. De ontwikkelaars achter de LibreSSL-fork spreken dan ook over een 'zeer slechte codebase' en zeggen de code flink te gaan opschonen.

En ook dat blijft IMHO echt in the eye of the beholder, wat de ene een goede codebase vindt, vindt een ander een ramp.. En mbt documentatie, tja, de ene vindt dat alles in een extern document moet staan, en de ander zegt 'goed geschreven code behoeft geen documentatie omdat het zichzelf wijst' maarja, zoals ik al zei, 'goed geschreven code' is in de the eye of the beholder..
Ook is het nogal een hype om om de zoveel jaar weer een nieuwe manier van code schrijven te bedenken, waarbij dan de oude manier als 'slecht' wordt bestempeld.. Joh, je moet toch wat doen he om te kunnen zeggen dat je gebruik moet maken van de allernieuwste IDE's/ontwikkelingstaal...
Tel daar ook nog de verschillende gedachtengangen bij op van wat men vindt dat goed is, dan kom je eigenlijk uit dat het enige wat je kunt doen is zorgen dat er binnen 1 project/bedrijf gewoon goede regels zijn opgesteld (en deze SAMEN op te stellen en niet door 1 iemand die misschien een beperkte kijk heeft)..
Maargoed, anderen zullen het hier niet mee eens zijn en denken dat het wel heel goed mogelijk is om aan te geven wat goede en slechte code is..

Slim plan, na heartbleed zijn er nog een paar smerige lekken aan het licht gekomen. Het is alleen totaal niet in de media gekomen...