Meer met Maven – Maven Central via https

In elke editie zal Robert Scholte een probleem voorleggen en deze oplossen met behulp van Apache Maven om meer inzicht te geven in Maven zelf en de vele beschikbare plugins.

Vóór het tijdperk van Maven was het nog een “best practice” om aan je project een lib-map toe te voegen, waarin je alle jars plaatste om je code te kunnen compileren. Het gevolg was dat er heel veel dezelfde jars over je harde schijven verspreid stonden en dat je ze steeds kopieerde van het ene naar het andere project. En aangezien je niet wist waar de jar oorspronkelijk vandaan kwam was het een kwestie van hopen dat je collega’s het via betrouwbare bronnen van het internet hadden geplukt.

Eén van de doelstellingen van Maven was om dit probleem op te lossen. Je kreeg een local repository, waarin al je jars met versie werden verzameld en waarnaar je alleen maar hoefde te verwijzen vanuit je project. En Maven Central werd geïntroduceerd: een online bibliotheek voor open source libraries. Voortaan hoef je slechts in je project aan te geven welke libraries je nodig hebt en Maven zorgt ervoor dat deze gedownload worden.

Maven Central werd steeds populairder en ook andere build management tools als Ivy en Gradle zorgden ervoor dat ze gebruik konden maken van bibliotheek. Eindelijk hoefde je nooit meer handmatig je dependencies te downloaden en had je een betrouwbare bron. Dit leek altijd heel veilig: je download immers wat pommetjes en artifacts. Totdat het besef er kwam, dat ze theoretisch onderweg gemanipulieerd kunnen worden door kwaadwillenden.

Tijdens de JFall 2012 liet Sander Mak al tijdens een presentatie zien hoe belangrijk het kan zijn om je artifacts over https naar binnen te halen. Ter plekke werd een live demonstratie gegeven van een man-in-the-middle attack: een stukje code werd gecompileerd en vervolgens uitgevoerd. Het resultaat kwam niet(!) overeen met de verwachte uitkomsten op basis van de code. In het kort kwam het erop neer, dat Sander niet de officiële maven-compiler-plugin had binnengehaald. In plaats daarvan had hij een verrijkte versie binnengekregen, die de code kan manipuleren voordat het gecompileerd wordt.

De optie om deze variant van hacken tegen te gaan is door gebruik te maken van een https verbinding. Daarmee wordt geverifieerd dat de gevraagde artifacts daadwerkelijk vanaf Maven Central komen. Sinds oktober 2012 bood Sonatype, de beheerder van Maven Central, certificaten aan voor een bedrag van $10, welke vervolgens aan de open source community gedoneerd zou worden. Tot op heden zijn er slecht twaalf(!) certificaten uitgedeeld.

Dit heeft Sonatype aan het denken gezet: moet de gebruiker verantwoordelijk zijn voor zijn eigen bescherming of moeten de tools dat doen? Aangezien nu wel blijkt dat de gebruiker zich niet bewust is van de gevaren, heeft Sonatype deze verantwoordelijkheid op zich genomen. Maven Central is voortaan voor iedereen via https te benaderen.

Vanuit het Apache Maven-team vonden we deze aanpassing belangrijk genoeg om versneld een nieuwe release van Maven de deur uit te doen. Vanaf Maven-3.2.3 maak je automatisch gebruik van deze beveiligde verbinding.

Dit is mooi voor de situaties, waarbij Maven rechtstreeks koppelt met Maven Central, maar ik ga ervan uit dat de meeste bedrijven gebruik maken van een repository manager. Uiteraard is Nexus, de repository manager van Sonatype zelf, de eerste die dit heeft aangepast. Vanaf versie 2.9 wordt standaard gebruikt gemaakt van de https verbinding om met Maven Central te koppelen. Mocht je niet kunnen upgraden, dan wordt uiteraard geadviseerd om de URL naar Maven Central zo snel mogelijk aan te passen.

Op http://central.sonatype.org/pages/consumers.html houdt Sonatype bij vanaf welke versie een bepaald product standaard gebruik maakt van https en hoe je het bij eerdere versies zelf kunt aanpassen.

Het volledige verhaal is te vinden op http://blog.sonatype.com/2014/07/ssl_connectivity_for_central