OpenSSL wil verder onder Apache 2.0-licentie, mag dat?

| AE 9339 | Intellectuele rechten | 13 reacties

Het OpenSSL-project wil overstappen van zijn eigen gebruikslicentie naar de Apache 2.0-licentie. Voor de overstap is de goedkeuring nodig van iedereen die als auteur mee heeft gewerkt aan de code van OpenSSL. Dat meldde Tweakers zaterdag. Het opensourceproject heeft een simpele BSD-achtige licentie maar met een irritante advertising-clausule, waar men nu vanaf wil. En overstappen naar de zeer standaard en breed gedragen Apache licentie ligt dan voor de hand. Alleen, krijgen ze dat voor elkaar?

OpenSSL is een veelgebruikte library voor het opzetten van beveiligde internetverbindingen. Het project is relatief oud: in 1998 verscheen de eerste versie van de software. Het concept open source was toen vrij nieuw, en daarom hanteerde men een eigen licentie die net even anders was dan andere. In principe is de licentie gelijk aan de BSD licentie, zij het ook wordt vereist dat alle advertenties voor afgeleide werken vermelden:

[T]his product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit

Dit is op zichzelf hooguit een tikje irritant maar de specifieke formulering van deze clausule maakte OpenSSL notoir GPL-incompatibel. En dat is vervelend als je bedenkt hoe veel GPL software er is die op zich best SSL-functionaliteit zou kunnen gebruiken. (Het GNU TLS project van later datum was er denk ik niet gekomen als OpenSSL deze bepaling niet had gehad.) Daarnaast is er nog een ambigue formulering in de licentie die de indruk wekt dat je de code niet mag integreren in een groter werk dat onder een andere licentie aangeboden wordt, wat volgens mij juridisch niet klopt maar goed discussie hou je altijd.

Het is dus méér dan de hoogste tijd voor het project om over te stappen naar iets moderns, en de Apache 2.0 is een prima keuze in dat verband.

Alleen, dat is een tikje ingewikkeld bij zo’n oud project want relicensing kan alleen als je van alle auteursrechthebbenden op de code toestemming hebt. En vind die maar eens na 20 jaar; het zou gaan om zo’n 1.000 mensen, volgens Tweakers.

Begrijpelijk dan ook dat het project heeft gekozen voor stilzwijgen is toestemming (als ik het goed lees, ik kan in het persbericht dit niet expliciet vinden). In theorie kan dat ook; vrijwel elk rechtsstelsel (ook Nederland) erkent dat rechtshandelingen door stilzwijgen kunnen worden verricht, zij het dat er vaak wel hoge eisen gelden aan duidelijkheid en intentie. Dat maakt het vaak lastig om (afgezien van zeer evidente situaties) je te beroepen op stilzwijgen als toestemming.

Hier zou die toestemming dan verkregen worden door naar het laatst bekende mailadres te mailen “Wij gaan uw code Apache 2.0 maken, graag reageren als u dat niet wilt”. Daar zit genoeg foutmarge in: het mailadres werkt niet meer, mail wordt stilletjes weggegooid, men wilde wel reageren maar de reactie kwam niet aan, de partij in kwestie ligt in het ziekenhuis en zijn mail stapelt zich op, en ga zo maar door. Dus of dat juridisch houdt, betwijfel ik.

Maar ja, wat moet je anders? De enige echte optie is dan om alle code te herschrijven waarvan geen expliciete toestemming is verkregen tot herlicentiëring. Dat lijkt me een hele bak werk, waar weinig eer aan te behalen valt.

Arnoud

Mag ik mensen laten checken of hun OpenSSL aan Heartbleed lijdt?

| AE 6552 | Security | 24 reacties

heartbleed-bug-openssl-securityEen kritieke bug in beveiligingssoftware OpenSSL heeft het jarenlang mogelijk gemaakt om wachtwoorden en andere geheime data van servers te achterhalen. Voor hackers, maar ook de NSA, zo is gebleken. De pijnlijke fout, die Heartbleed is genoemd, is zeer wijdverspreid. Logisch dus dat mensen nu tools ontwikkelen om te zien of een site kwetsbaar is. Maar mag dat eigenlijk wel?

De kwetsbaarheid in de OpenSSL software zit hem in een stukje code dat wordt gebruikt om een beveiligde verbinding ‘open’ te houden. Om dat te doen, stuurt de client periodiek een signaal naar de server, die dan een korte reactie geeft. Een soort meten van de hartslag van de server; leeft hij nog? De reactie bestaat uit een kopie van het signaal, oftewel je herhaalt als server wat de client net tegen je zet (“Hallo?” “Hallo!” zeg maar).

Bij dat signaal staat hoe lang het is. En het probleem is dat de server dat opgegeven aantal bytes terugstuurt, ongeacht hoe lang de boodschap feitelijk was. Zeg je dus “64Hallo?” dan krijg je 64 tekens terug, waarvan de eerste vijf “Hallo?” zijn en de rest wat er toevallig in het servergeheugen staat. Dat kan dus van alles zijn, inclusief wachtwoorden en sessie-tokens van anderen. Zie ook deze xkcd. Daar gaat mijn hart ook wel even van bloeden ja.

Je site testen of deze kwetsbaar is, is dus zeer verstandig. Daar zijn tools voor, en natuurlijk is het volstrekt legaal dat te doen op je eigen site. Maar een hoop mensen willen ook testen of andere sites kwetsbaar zijn, bijvoorbeeld omdat ze daar hun webmail of andere belangrijke diensten hebben ondergebracht. Of omdat ze journalistiek nieuwsgierig zijn. Of omdat ze in willen breken. En daar ga je dan, juridisch: mág dat dan wel, andermans site testen op deze veiligheid?

Testen van een kwetsbaarheid is in theorie te zien als computervredebreuk. Het is van dezelfde orde als testen of iemands achterdeurslot met een balpen te openen is. Je dringt binnen in de server en verschaft je toegang tot gegevens waarvoor je niet geautoriseerd bent. Het gaat iets verder dan een portscan, waarbij je immers alleen maar legale verzoeken doet aan de server (“Dag, doet u aan POP3 of NTP?”) en de informatie die je dan krijgt, gebruikt om in te breken. Het testen op de Heartbleed-fout levert je meer informatie op dan de bedoeling is. Dus formeel ben je strafbaar.

Gezien de grote impact van de fout denk ik toch dat dit juridisch niet bezwaarlijk moet zijn. Wel moet je een duidelijk belang hebben bij het testen van die site én de beheerders op de hoogte stellen van de fout. Misbruik maken van de gevonden gegevens maakt het echt strafbaar.

Natuurlijk kun je zeggen, het is niet jouw taak om andermans websites te testen. Dat moeten ze zelf doen. Dat is ook zo. Alleen het teleurstellende feit is dat veel mensen dat gewoon niet dóen. En omdat ze daarmee ánderen in gevaar brengen (in tegenstelling tot dat achterdeurslot, waar ze alleen zelf last van hebben) vind ik het maatschappelijk verantwoord om dan toch aan de bel te trekken: “hoi, je bloedt andermans gegevens, dóe iets”.

Diverse mensen vroegen me ook of ze een site mogen opzetten die onderzoekt of een gegeven website kwetsbaar is (zoals Filippo). Ik denk dat dat wel mag, mits je de tool maar zo voorzichtig mogelijk opzet. Het liefst zegt hij alleen “ja/nee”, een datadump van wat de server lekt (bloedt?) laat zien, gaat echt te ver. En je zou nog een vertraging in kunnen bouwen. Eén site testen prima, twee of drie nou vooruit, maar wie twintig sites achter elkaar gaat testen is een beetje raar.

Helemaal netjes zou zijn dat je zegt, installeer eerst een bepaald bestandje op je website met een unieke naam, en dan controleert of dat bestandje bestaat op die website voordat je de test uitvoert. Dan weet je zeker dat de gebruiker aan de website gelieerd is. Maar dat voelt wat zwaar voor één korte test.

Arnoud