De laatste tijd trekt WireGuard veel aandacht; het is in feite de nieuwe "ster" onder VPN. Maar is het echt zo goed als het lijkt? Ik wil enkele observaties bespreken en de implementatie van WireGuard bekijken om uit te leggen waarom het geen oplossing is die IPsec of OpenVPN vervangt.
In dit artikel wil ik enkele mythen [over WireGuard] ontkrachten. Ja, het zal een lange read zijn, dus als je nog geen kopje thee of koffie hebt gezet, is dit het moment om dat te doen. Ik wil ook Peter bedanken voor het redigeren van mijn chaotische gedachten.
Het is niet mijn bedoeling om de ontwikkelaars van WireGuard te discrediteren, hun inspanningen of ideeƫn te verlagen. Hun product is functioneel, maar persoonlijk vind ik dat het op een totaal andere manier wordt gepresenteerd dan het in werkelijkheid is - gepresenteerd als een vervanging voor IPsec en OpenVPN, waarvan op dit moment gewoon geen sprake is.
Als opmerking wil ik toevoegen dat de verantwoordelijkheid voor deze verkeerde positionering van WireGuard ligt bij de media die erover hebben bericht, en niet bij het project zelf of zijn makers.
Laatst was er niet veel goed nieuws over de Linux-kernel. Er waren verschrikkelijke kwetsbaarheden in de processors die op softwarematige wijze waren opgelost, terwijl Linus Torvalds hier te grof en saai over sprak, in een utilitaire ontwikkelaarsstaal. De planner of de netwerkstack van nul niveau zijn ook niet al te begrijpelijke onderwerpen voor glossy tijdschriften. En hier komt WireGuard om de hoek kijken.
Op papier klinkt het geweldig: een verbluffende nieuwe technologie.
Maar laten we het iets nader bekijken.
De technische documentatie van WireGuard
Dit artikel is gebaseerd op de officiƫle documentatie van WireGuard, geschreven door Jason Donenfeld. Daarin legt hij het concept, de doelstellingen en de technische implementatie [van WireGuard] in de Linux-kernel uit.
De eerste zin luidt:
WireGuard [ā¦] streeft ernaar om in de meeste gebruikssituaties zowel IPsec als andere populaire oplossingen op basis van de gebruikersruimte en/of TLS, zoals OpenVPN, te vervangen, terwijl het een veiliger, meer performant en gebruiksvriendelijker [hulpmiddel] is.
Natuurlijk is het belangrijkste voordeel van alle nieuwe technologieƫn hun eenvoud [in vergelijking met voorgangers]. Maar een VPN moet ook effectief en veilig zijn..
En wat nu?
Als u zegt dat u niet dit van [VPN] nodig heeft, dan kan de lectuur hier eindigen. Ik wil echter opmerken dat dergelijke taken ook aan andere tunnelingtechnologieƫn worden gesteld.
Het meest interessante uit het bovenstaande citaat schuilt in de woorden āin de meeste gevallenā, die vanzelfsprekend door de pers zijn genegeerd. En hier zijn we, waar we zijn beland door de chaos die deze nalatigheid heeft gecreĆ«erd - in dit artikel.
Zal WireGuard een vervanging worden voor mijn [IPsec] VPN-verbinding tussen sites?
Nee. Er is gewoon geen kans dat grote leveranciers zoals Cisco, Juniper en anderen WireGuard voor hun producten zullen aankopen. Ze springen niet zomaar op voorbijrijdende treinen, tenzij daar een grote noodzaak voor is. Later zal ik enkele redenen uitleggen waarom zij waarschijnlijk WireGuard niet zullen kunnen implementeren in hun producten, zelfs als ze dat zouden willen.
Zal WireGuard mijn RoadWarrior van een laptop naar een datacenter verplaatsen?
Nee. Op dit moment mist WireGuard een groot aantal belangrijke functies om iets dergelijks te kunnen doen. Bijvoorbeeld, het kan geen dynamische IP-adressen aan de serverzijde van de tunnel gebruiken, en dat alleen al breekt het hele scenario voor dit product.
IPFire wordt vaak gebruikt voor goedkope internetverbindingen, zoals DSL of kabelverbindingen. Dit is logisch voor kleine of middelgrote bedrijven die geen snelle glasvezel hoeven. [Opmerking van de vertaler: vergeet niet dat Rusland en sommige landen van de GOS veel verder gevorderd zijn dan Europa en de VS op het gebied van verbinding, omdat we onze netwerken veel later zijn gaan opbouwen en met de komst van Ethernet en glasvezelnetwerken als standaard ons makkelijker was om over te schakelen. In dezelfde landen van de EU of de VS is xDSL-breedband met snelheden van 3-5 Mbps nog steeds de algemene norm, terwijl een glasvezelverbinding onrealistisch dure bedragen kost volgens onze maatstaven. Daarom spreekt de auteur van het artikel over DSL- of kabelverbindingen als de norm en niet als obsoliete technologie.] Echter, DSL, kabel, LTE (en andere draadloze toegangsmethoden) hebben dynamische IP-adressen. Natuurlijk veranderen ze af en toe niet vaak, maar ze veranderen nog steeds.
Er is een subproject onder de naam Ā«wg-dynamicĀ», die een gebruikersruimte demon toevoegt om dit tekort te overbruggen. Een groot probleem met het hierboven beschreven gebruiksscenario is de verslechtering door dynamische IPv6-adressering.
Vanuit het perspectief van de distributeur ziet dit er ook niet goed uit. Een van de doelstellingen van de ontwikkeling was het behoud van de eenvoud en de zuiverheid van het protocol.
Helaas is dit allemaal te eenvoudig en primitief geworden, waardoor we extra software moeten gebruiken om ervoor te zorgen dat deze constructie levensvatbaar is in de echte wereld.
Is WireGuard zo gemakkelijk te gebruiken?
Tot nu toe niet. Ik zeg niet dat WireGuard nooit een goede alternatief zal zijn voor het opzetten van een tunnel tussen twee punten, maar voorlopig is het slechts een alfa-versie van het product dat het zou moeten zijn.
Maar wat doet het dan eigenlijk? Is IPsec echt zo veel moeilijker in gebruik?
Blijkbaar niet. De IPsec-aanbieder heeft hieraan gedacht en levert zijn product met een interface, bijvoorbeeld met IPFire.
Voor het instellen van een VPN-tunnel via IPsec heeft u vijf gegevenssets nodig die in de configuratie moeten worden ingevoerd: uw eigen publieke IP-adres, het publieke IP-adres van de ontvangende partij, de subnets die u openbaar wilt maken via deze VPN-verbinding en de pre-shared key. Op deze manier wordt de VPN in enkele minuten ingesteld en is deze compatibel met elke leverancier.
Helaas zijn er enkele uitzonderingen in dit verhaal. Iedereen die heeft geprobeerd een VPN-tunnel via IPsec naar een machine op OpenBSD op te zetten, weet waar ik het over heb. Er zijn een paar pijnlijke voorbeelden, maar in werkelijkheid zijn er veel en veel meer positieve ervaringen met IPsec.
Over de complexiteit van het protocol
De eindgebruiker zou zich geen zorgen moeten maken over de complexiteit van het protocol.
Als we in een wereld leefden waar dit een echte zorg voor de gebruiker was, zouden we allang af zijn van SIP, H.323, FTP en andere protocollen die meer dan tien jaar geleden zijn gemaakt en slecht werken met NAT.
Er zijn redenen waarom IPsec ingewikkelder is dan WireGuard: het doet veel meer dingen. Bijvoorbeeld, gebruikersauthenticatie met een gebruikersnaam/wachtwoord of een SIM-kaart met EAP. Het heeft uitgebreide mogelijkheden voor het toevoegen van nieuwe cryptografische primitieven.
En WireGuard heeft dat niet.
Dit betekent dat WireGuard op een gegeven moment zal falen, omdat een van de cryptografische primitieve verzwakt of volledig gecompromitteerd zal worden. De auteur van de technische documentatie zegt hierover het volgende:
Het is vermeldenswaard dat WireGuard cryptografisch zelfverzekerd is. Het mist opzettelijk de flexibiliteit van cipher en protocollen. Als er serieuze gaten in de onderliggende primitieve worden ontdekt, zullen alle eindpunten moeten worden bijgewerkt. Zoals blijkt uit de voortdurende stroom van kwetsbaarheden in SSL/TLS, is de flexibiliteit in encryptie nu enorm toegenomen.
De laatste zin is absoluut juist.
Consensus bereiken over welke encryptie moet worden gebruikt, maakt protocollen zoals IKE en TLS meer dan complex. Te complex? Ja, kwetsbaarheden in TLS/SSL komen vaak voor en er zijn geen alternatieven.
Over het negeren van echte problemen
Stel je voor dat je een VPN-server hebt met 200 actieve klanten, verspreid over de hele wereld. Dit is een vrij gebruikelijk gebruiksscenario. Als je de encryptie moet wijzigen, moet je de update naar alle kopieƫn van WireGuard op deze laptops, smartphones, enzovoort versturen. Tegelijkertijd verzenden. Dit is letterlijk onmogelijk. Beheerders die dit proberen, zullen maanden nodig hebben om de benodigde configuraties uit te rollen, en voor gemiddelde bedrijven kan dit letterlijk jaren duren.
IPsec en OpenVPN bieden functie voor cipheronderhandeling. Daarom zal er enige tijd zijn waarin, nadat je de nieuwe encryptie inschakelt, ook de oude nog functioneert. Hierdoor kunnen huidige klanten upgraden naar de nieuwe versie. Nadat de update is uitgerold, zet je simpelweg de kwetsbare encryptie uit. En dat is het! Klaar! Je bent geweldig! En de klanten merken er niets van.
Dit is in feite een veelvoorkomende situatie voor grote uitrol, en zelfs OpenVPN heeft hier wat moeite mee. Terugwaartse compatibiliteit is belangrijk, en hoewel je zwakkere encryptie gebruikt, betekent dit voor velen niet dat het bedrijf sluit. Want dit zou leiden tot een stilstand voor honderden klanten vanwege hun onvermogen om hun werk uit te voeren.
Het WireGuard-team heeft zijn protocol eenvoudiger gemaakt, maar het is volledig ongeschikt voor mensen die geen constante controle hebben over beide peers van hun tunnel. Uit mijn ervaring is dit soort scenario het meest voorkomend.
Cryptografie!
Maar wat is dat interessante nieuwe encryptie dat WireGuard gebruikt?
WireGuard maakt gebruik van Curve25519 voor sleuteldistributie, ChaCha20 voor encryptie en Poly1305 voor gegevensauthenticatie. Het werkt ook met SipHash voor hash-sleutels en BLAKE2 voor hashing.
ChaCha20-Poly1305 is gestandaardiseerd voor IPsec en OpenVPN (via TLS).
Het is duidelijk dat de ontwikkeling van Daniel Bernstein zeer vaak wordt gebruikt. BLAKE2 is de opvolger van BLAKE, de finalist van SHA-3, die niet gewonnen heeft vanwege de gelijkenis met SHA-2. Als SHA-2 is gecompromitteerd, was er een grote kans dat ook BLAKE gecompromitteerd zou zijn.
IPsec en OpenVPN hebben geen SipHash nodig vanwege hun ontwerp. Het enige dat momenteel niet met hen kan worden gebruikt, is BLAKE2, en dat alleen totdat het gestandaardiseerd is. Dit is geen groot nadeel, omdat VPN HMAC gebruikt om integriteit te creƫren, wat als een sterke oplossing wordt beschouwd, zelfs in combinatie met MD5.
Dus concludeer ik dat praktisch dezelfde set cryptografische tools in alle VPN's wordt gebruikt. Daarom is WireGuard niet meer en niet minder veilig dan andere actuele producten als het gaat om encryptie of integriteit van verzonden gegevens.
Maar zelfs dat is niet het belangrijkste om op te letten volgens de officiƫle documentatie van het project. Het belangrijkste is de snelheid.
Is WireGuard sneller dan andere VPN-oplossingen?
Kort gezegd: nee, het is niet sneller.
ChaCha20 is een streamcipher dat gemakkelijker te implementeren is in software. Het versleutelt Ć©Ć©n bit per keer. Blokprotocols, zoals AES, versleutelen blokken van 128 bits tegelijkertijd. Voor hardwarematige ondersteuning zijn veel meer transistors nodig, daarom worden grotere processors geleverd met AES-NI ā een instructiesetuitbreiding die sommige taken van het encryptieproces uitvoert om het te versnellen.
Er werd verwacht dat AES-NI nooit in smartphones zou komen [maar het is er wel in terechtgekomen ā red.]. Daarom is ChaCha20 ontwikkeld als een lichte en energiezuinige alternatieve oplossing die de batterij ontziet. Het kan dus verrassend zijn dat elke smartphone die je tegenwoordig kunt kopen, enige vorm van AES-versnelling heeft en sneller met deze encryptie werkt en minder energie verbruikt dan met ChaCha20.
Het is duidelijk dat praktisch elke processor voor desktops / servers die de afgelopen paar jaar is gekocht, AES-NI heeft.
Daarom verwacht ik dat AES ChaCha20 in elk afzonderlijk scenario zal overtreffen. In de officiƫle documentatie van WireGuard wordt vermeld dat ChaCha20-Poly1305 dankzij AVX512 beter zal presteren dan AES-NI, maar deze extensie van de instructieset is alleen beschikbaar op grotere processors, wat opnieuw niet helpt voor kleinere en mobiele apparaten, die altijd sneller met AES-NI zullen werken.
Ik weet niet zeker of dit kon worden voorzien bij de ontwikkeling van WireGuard, maar het feit dat het aan Ć©Ć©n encryptie is gebonden, is nu al een tekortkoming die de prestaties mogelijk niet ten goede komt.
IPsec stelt je in staat om vrij te kiezen welke encryptie het beste bij je situatie past. En dat is noodzakelijk als je bijvoorbeeld 10 gigabyte of meer gegevens via een VPN-verbinding wilt verzenden.
Integratieproblemen in Linux
Hoewel WireGuard een modern encryptieprotocol heeft gekozen, leidt dit al tot veel problemen. En in plaats van gebruik te maken van wat standaard door de kernel wordt ondersteund, wordt de integratie van WireGuard al jaren uitgesteld vanwege het ontbreken van deze primitieve componenten in Linux.
Ik ben niet volledig op de hoogte van de situatie in andere besturingssystemen, maar het is waarschijnlijk niet veel anders dan de situatie met Linux.
Hoe ziet de werkelijkheid eruit?
Helaas, iedere keer dat een klant me vraagt om een VPN-verbinding voor hem in te stellen, stuit ik op het probleem dat ze verouderde inloggegevens en encryptie gebruiken. 3DES in combinatie met MD5 is nog steeds een veelvoorkomende praktijk, net als AES-256 en SHA1. En hoewel de laatste iets beter is, is het niet iets waar je in 2020 mee zou moeten werken.
Voor het uitwisselen van sleutels altijd wordt RSA gebruikt ā een trage, maar voldoende veilige methode.
Mijn klanten hebben verbinding met douaneautoriteiten en andere staatsorganen en instellingen, evenals met grote bedrijven waarvan de namen wereldwijd bekend zijn. Al deze bedrijven gebruiken een aanvraagformulier dat decennia geleden is gemaakt, en de mogelijkheid om SHA-512 te gebruiken is gewoon nooit toegevoegd. Ik kan niet zeggen dat dit op een duidelijke manier invloed heeft op de technologische vooruitgang, maar het vertraagt duidelijk de bedrijfsprocessen.
Het doet me pijn om dit te zien, want IPsec ondersteunt elliptische krommen al sinds 2005. Curve25519 is ook nieuwer en beschikbaar voor gebruik. Er zijn ook alternatieven voor AES, zoals Camellia en ChaCha20, maar niet alle worden uiteraard ondersteund door grote leveranciers zoals Cisco en anderen.
En mensen maken hier gebruik van. Er zijn veel Cisco-pakketten, er zijn tal van sets die zijn ontworpen om met Cisco te werken. Ze zijn marktleider in deze sector en zijn niet echt geĆÆnteresseerd in innovaties.
Ja, de situatie [in de zakelijke sector] is vreselijk, maar we zullen geen veranderingen zien door WireGuard. Fabrikanten zullen waarschijnlijk nooit enige prestatieproblemen met de reeds gebruikte tools en encryptie aan het licht brengen, en ze zullen geen problemen zien bij het gebruik van IKEv2 ā en daarom zoeken ze niet naar alternatieven.
Heb je ooit nagedacht over het afschaffen van Cisco?
Benchmarks
Laten we nu overgaan tot de benchmarks uit de documentatie van WireGuard. Hoewel deze [documentatie] geen wetenschappelijk artikel is, had ik toch van de ontwikkelaars een meer wetenschappelijke benadering verwacht, of het gebruik van een wetenschappelijke benadering als referentie. Elke benchmark is nutteloos als deze niet reproduceerbaar is, en des te nuttelozer als deze onder laboratoriumomstandigheden is verkregen.
In de WireGuard-build voor Linux profiteert het van GSO ā Generic Segmentation Offloading. Hierdoor kan de client een enorme pakketgrootte van 64 kilobyte creĆ«ren en deze in Ć©Ć©n keer versleutelen/ontsleutelen. Hiermee worden de kosten voor het oproepen en implementeren van cryptografische operaties verlaagd. Als je de bandbreedte van je VPN-verbinding wilt maximaliseren, is dit een goed idee.
Maar zoals gebruikelijk is, is niet alles in de praktijk zo eenvoudig. Het verzenden van zo'n grote pakket naar de netwerkadapter vereist dat het in vele kleinere pakketten wordt opgedeeld. De gebruikelijke verzendgrootte bedraagt 1500 bytes. Dat wil zeggen dat onze reus van 64 kilobytes zal worden opgedeeld in 45 pakketten (1240 bytes informatie en 20 bytes IP-header). Vervolgens blokkeren ze tijdelijk volledig het werk van de netwerkadapter, omdat ze samen en tegelijk moeten worden verzonden. Dit zal uiteindelijk leiden tot een prioriteitssprong, waardoor pakketten zoals VoIP in de wachtrij worden gezet.
Zo wordt de hoge bandbreedte die WireGuard zo vrijmoedig beweert te bereiken, gerealiseerd ten koste van de netwerkaansluiting van andere applicaties. En het team van WireGuard heeft al bevestigde dit is mijn conclusie.
Maar laten we verder gaan.
Volgens benchmarks in de technische documentatie toont de verbinding een bandbreedte van 1011 Mbps.
Indrukwekkend.
Dit is bijzonder indrukwekkend, aangezien de maximale theoretische bandbreedte van een Gigabit Ethernet-verbinding 966 Mbps bedraagt bij een pakketgrootte van 1500 bytes min 20 bytes voor de IP-header, 8 bytes voor de UDP-header en 16 bytes voor de header van WireGuard zelf. Er is nog een andere IP-header in het ingekapselde pakket en een andere van 20 bytes in TCP. Hoe kwam deze extra bandbreedte tot stand?
Met grote frames en de voordelen van GSO, waar we het eerder over hadden, zal de theoretische maximum bij een framegrootte van 9000 bytes gelijk zijn aan 1014 Mbps. Gewoonlijk is zo'n bandbreedte in de praktijk niet haalbaar vanwege de grote moeilijkheden die ermee gepaard gaan. Ik kan dus alleen maar veronderstellen dat de test is uitgevoerd met nog grotere frames die de grootte van 64 kilobytes overschrijden, met een theoretisch maximum van 1023 Mbps, wat slechts door sommige netwerkadapters wordt ondersteund. Maar dit is absoluut niet toepasbaar onder reƫle omstandigheden, of kan alleen worden gebruikt tussen twee direct verbonden stations, uitsluitend binnen een testopstelling.
Maar omdat de VPN-tunnel via een internetverbinding tussen twee hosts gaat die helemaal geen grote frames ondersteunt, kan het resultaat dat op de teststand is bereikt niet als norm worden beschouwd. Het is gewoon een onrealistische laboratoriumprestatie die niet mogelijk is en niet toepasbaar is in echte strijdomstandigheden.
Zelfs vanuit het datacenter zou ik geen frames groter dan 9000 bytes kunnen doorsturen.
De criterium voor toepasbaarheid in het echte leven is absoluut geschonden en, zoals ik denk, heeft de auteur van de āmetingā zichzelf serieus in diskrediet gebracht om duidelijke redenen.
De laatste sprankje hoop
Op de WireGuard-website wordt veel gesproken over containers en het wordt duidelijk waarvoor het in feite bedoeld is.
Een eenvoudige en snelle VPN die geen configuratie vereist en kan worden ingezet en geconfigureerd met massale orkestratietools, zoals bijvoorbeeld die van Amazon in hun cloud. Specifiek gebruikt Amazon de nieuwste hardwarefuncties waar ik eerder over sprak, zoals AVX512. Dit wordt gedaan om de prestaties te versnellen en niet gebonden te zijn aan x86 of enige andere architectuur.
Zij optimaliseren de bandbreedte en de pakketten, waarvan de grootte 9000 bytes overschrijdt ā dit resulteert in enorme ingekapselde frames voor communicatie tussen containers, of voor back-upoperaties, het maken van snapshots of het inzetten van deze containers. Zelfs dynamische IP-adressen zullen de werking van WireGuard in het door mij beschreven scenario niet beĆÆnvloeden.
Goed gespeeld. Een schitterende implementatie en een zeer verfijnd, bijna referentieprotocol.
Maar het is gewoon niet geschikt voor de wereld buiten een datacenter dat je volledig beheert. Als je het aandurft om WireGuard te gebruiken, moet je constant compromissen sluiten bij het ontwikkelen en implementeren van het encryptieprotocol.
Uitslag
Ik kan gemakkelijk concluderen dat WireGuard momenteel nog niet klaar is.
Het was bedoeld als een vereenvoudigde en snelle oplossing voor een aantal problemen van bestaande oplossingen. Helaas heeft het voor deze oplossingen veel functies opgeofferd die voor de meeste gebruikers relevant zullen zijn. Daarom kan het IPsec of OpenVPN niet vervangen.
Om WireGuard concurrerend te maken, moet het ten minste de mogelijkheid hebben om een IP-adres en configuratie voor routing en DNS toe te voegen. Het is duidelijk dat hiervoor versleutelde kanalen nodig zijn.
Veiligheid is mijn hoogste prioriteit, en op dit moment heb ik geen reden om aan te nemen dat IKE of TLS op de een of andere manier gecompromitteerd of gebroken zijn. Modern encryptie wordt in beide ondersteund en ze zijn gedurende tientallen jaren getest. Het feit dat iets nieuwer is, betekent niet dat het beter is.
Functionele compatibiliteit is uiterst belangrijk wanneer je verbinding maakt met derden wiens stations je niet controleert. IPsec is de facto de standaard en wordt vrijwel overal ondersteund. Het werkt. En hoe het ook moge lijken, theoretisch kan WireGuard in de toekomst incompatibel zijn met verschillende versies van zichzelf.
Elke cryptografische bescherming wordt vroeg of laat gekraakt en moet daarom worden vervangen of bijgewerkt.
Het ontkennen van al deze feiten en de blinde wens om WireGuard te gebruiken om je iPhone met je thuiswerkstation te verbinden, is gewoon een masterclass in het verstoppen van je hoofd in het zand.
Bron: habr.com
