WireGuard krijgt de laatste tijd veel aandacht, het is zelfs de nieuwe ster onder de VPN's. Maar is hij wel zo goed als hij lijkt? Ik wil graag enkele observaties bespreken en de implementatie van WireGuard bekijken om uit te leggen waarom het geen oplossing is om IPsec of OpenVPN te vervangen.
In dit artikel wil ik enkele mythen [rond WireGuard] ontkrachten. Ja, het zal lang duren om te lezen, dus als je nog geen kopje thee of koffie hebt gezet, dan is het tijd om het te doen. Ook wil ik Peter bedanken voor het corrigeren van mijn chaotische gedachten.
Ik stel mezelf niet tot doel de ontwikkelaars van WireGuard in diskrediet te brengen, hun inspanningen of ideeën te devalueren. Hun product werkt, maar persoonlijk denk ik dat het totaal anders wordt gepresenteerd dan het in werkelijkheid is - het wordt gepresenteerd als vervanging voor IPsec en OpenVPN, die nu in feite gewoon niet bestaan.
Als opmerking wil ik hieraan toevoegen dat de verantwoordelijkheid voor een dergelijke positionering van WireGuard bij de media ligt die erover spraken, en niet bij het project zelf of de makers ervan.
Er is de laatste tijd niet veel goed nieuws over de Linux-kernel. Dus werd ons verteld over de monsterlijke kwetsbaarheden van de processor, die door software werden geëgaliseerd, en Linus Torvalds sprak er te grof en saai over, in de utilitaire taal van de ontwikkelaar. Een planner of een zero-level netwerkstack zijn ook geen erg duidelijke onderwerpen voor glossy magazines. En hier komt WireGuard.
Op papier klinkt het allemaal geweldig: een opwindende nieuwe technologie.
Maar laten we het wat nader bekijken.
WireGuard-witboek
Dit artikel is gebaseerd op geschreven door Jason Donenfeld. Daar legt hij het concept, het doel en de technische implementatie van [WireGuard] in de Linux-kernel uit.
De eerste zin luidt:
WireGuard […] is bedoeld om zowel IPsec in de meeste gebruikssituaties als andere populaire gebruikersruimte en/of op TLS gebaseerde oplossingen zoals OpenVPN te vervangen, terwijl het veiliger, performanter en gebruiksvriendelijker is [tool].
Het belangrijkste voordeel van alle nieuwe technologieën is natuurlijk hun verlichten [vergeleken met voorgangers]. Maar een VPN zou dat ook moeten zijn efficiënt en veilig.
Dus, wat is het volgende?
Als je zegt dat dit niet is wat je nodig hebt [van een VPN], dan kun je hier stoppen met lezen. Ik merk echter op dat dergelijke taken zijn ingesteld voor elke andere tunneltechnologie.
Het meest interessante van het bovenstaande citaat ligt in de woorden "in de meeste gevallen", die natuurlijk door de pers werden genegeerd. En dus zijn we waar we zijn geëindigd door de chaos die door deze nalatigheid is ontstaan - in dit artikel.
Zal WireGuard mijn [IPsec] site-to-site VPN vervangen?
Nee. Er is gewoon geen kans dat grote leveranciers zoals Cisco, Juniper en anderen WireGuard voor hun producten zullen kopen. Ze "springen niet op passerende treinen" terwijl ze onderweg zijn, tenzij er een grote behoefte is om dat te doen. Later zal ik enkele redenen bespreken waarom ze hun WireGuard-producten waarschijnlijk niet aan boord kunnen krijgen, zelfs als ze dat zouden willen.
Brengt WireGuard mijn RoadWarrior van mijn laptop naar het datacenter?
Nee. Op dit moment heeft WireGuard niet een groot aantal belangrijke functies geïmplementeerd om zoiets te kunnen doen. Het kan bijvoorbeeld geen gebruik maken van dynamische IP-adressen aan de kant van de tunnelserver, en dit alleen doorbreekt het hele scenario van een dergelijk gebruik van het product.
IPFire wordt vaak gebruikt voor goedkope internetverbindingen, zoals DSL- of kabelverbindingen. Dit is logisch voor kleine of middelgrote bedrijven die geen snelle glasvezel nodig hebben. [Opmerking van de vertaler: vergeet niet dat Rusland en sommige GOS-landen op het gebied van communicatie ver voorlopen op Europa en de Verenigde Staten, omdat we veel later begonnen met het bouwen van onze netwerken en met de komst van Ethernet en glasvezelnetwerken als een standaard was het voor ons gemakkelijker om te herbouwen. In dezelfde landen van de EU of de VS is xDSL-breedbandtoegang met een snelheid van 3-5 Mbps nog steeds de algemene norm, en een glasvezelverbinding kost naar onze maatstaven onrealistisch veel geld. Daarom spreekt de auteur van het artikel over DSL- of kabelverbindingen als de norm, en niet over de oudheid.] DSL, kabel, LTE (en andere draadloze toegangsmethoden) hebben echter dynamische IP-adressen. Natuurlijk veranderen ze soms niet vaak, maar ze veranderen wel.
Er is een deelproject genaamd , die een userspace-daemon toevoegt om deze tekortkoming te verhelpen. Een enorm probleem met het hierboven beschreven gebruikersscenario is de verergering van dynamische IPv6-adressering.
Vanuit het oogpunt van de distributeur ziet dit er ook allemaal niet erg goed uit. Een van de ontwerpdoelen was om het protocol eenvoudig en schoon te houden.
Helaas is dit alles eigenlijk te simpel en primitief geworden, zodat we aanvullende software moeten gebruiken om dit hele ontwerp levensvatbaar te maken in het echte gebruik.
Is WireGuard zo gebruiksvriendelijk?
Nog niet. Ik zeg niet dat WireGuard nooit een goed alternatief zal zijn voor tunneling tussen twee punten, maar voorlopig is het slechts een alfaversie van het product dat het zou moeten zijn.
Maar wat doet hij dan eigenlijk? Is IPsec echt zoveel moeilijker te onderhouden?
Duidelijk niet. De IPsec-leverancier heeft hieraan gedacht en levert hun product samen met een interface, zoals met IPFire.
Om een VPN-tunnel over IPsec op te zetten, heb je vijf sets gegevens nodig die je in de configuratie moet invoeren: je eigen openbare IP-adres, het openbare IP-adres van de ontvangende partij, de subnetten die je openbaar wilt maken via deze VPN-verbinding en vooraf gedeelde sleutel. De VPN is dus binnen enkele minuten opgezet en is compatibel met elke leverancier.
Helaas zijn er een paar uitzonderingen op dit verhaal. Iedereen die heeft geprobeerd via IPsec naar een OpenBSD-machine te tunnelen, weet waar ik het over heb. Er zijn nog een paar pijnlijke voorbeelden, maar in feite zijn er veel, veel meer goede praktijken voor het gebruik van IPsec.
Over protocolcomplexiteit
De eindgebruiker hoeft zich geen zorgen te maken over de complexiteit van het protocol.
Als we in een wereld zouden leven waar dit een echte zorg van de gebruiker was, dan zouden we SIP, H.323, FTP en andere protocollen die meer dan tien jaar geleden zijn gemaakt en die niet goed werken met NAT hebben verwijderd.
Er zijn redenen waarom IPsec complexer is dan WireGuard: het doet veel meer. Bijvoorbeeld gebruikersauthenticatie met een login/wachtwoord of een simkaart met EAP. Het heeft een uitgebreide mogelijkheid om nieuwe toe te voegen .
En WireGuard heeft dat niet.
En dit betekent dat WireGuard op een gegeven moment zal breken, omdat een van de cryptografische primitieven zal verzwakken of volledig gecompromitteerd zal zijn. De auteur van de technische documentatie zegt dit:
Het is vermeldenswaard dat WireGuard cryptografisch eigenwijs is. Het mist met opzet de flexibiliteit van cijfers en protocollen. Als er ernstige gaten worden gevonden in onderliggende primitieven, moeten alle eindpunten worden bijgewerkt. Zoals je kunt zien aan de voortdurende stroom van SLL/TLS-kwetsbaarheden, is de flexibiliteit van encryptie nu enorm toegenomen.
De laatste zin is helemaal correct.
Het bereiken van consensus over welke codering moet worden gebruikt, maakt protocollen zoals IKE en TLS meer complex. Te ingewikkeld? Ja, kwetsbaarheden komen vrij vaak voor in TLS/SSL en er is geen alternatief voor.
Over het negeren van echte problemen
Stel je voor dat je ergens ter wereld een VPN-server hebt met 200 gevechtsclients. Dit is een vrij standaard use-case. Als u de codering moet wijzigen, moet u de update leveren aan alle exemplaren van WireGuard op deze laptops, smartphones, enzovoort. Tegelijkertijd leveren. Het is letterlijk onmogelijk. Beheerders die dit proberen te doen, zullen maanden nodig hebben om de vereiste configuraties in te voeren, en het zal een middelgroot bedrijf letterlijk jaren kosten om zo'n evenement voor elkaar te krijgen.
IPsec en OpenVPN bieden een coderingsonderhandelingsfunctie. Daarom zal de oude enige tijd, waarna u de nieuwe codering inschakelt, ook werken. Hierdoor kunnen huidige klanten upgraden naar de nieuwe versie. Nadat de update is uitgerold, zet je de kwetsbare encryptie gewoon uit. En dat is het! Klaar! je bent prachtig! Klanten zullen het niet eens merken.
Dit is eigenlijk een veel voorkomend geval voor grote implementaties, en zelfs OpenVPN heeft hier wat moeite mee. Achterwaartse compatibiliteit is belangrijk, en hoewel u een zwakkere codering gebruikt, is dit voor velen geen reden om een bedrijf te sluiten. Omdat het het werk van honderden klanten zal verlammen vanwege het onvermogen om hun werk te doen.
Het WireGuard-team heeft hun protocol eenvoudiger gemaakt, maar volledig onbruikbaar voor mensen die niet constant controle hebben over beide peers in hun tunnel. In mijn ervaring is dit het meest voorkomende scenario.
Cryptografie!
Maar wat is deze interessante nieuwe codering die WireGuard gebruikt?
WireGuard gebruikt Curve25519 voor sleuteluitwisseling, ChaCha20 voor codering 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 heel vaak wordt gebruikt. BLAKE2 is de opvolger van BLAKE, een SHA-3-finalist die niet won vanwege de gelijkenis met SHA-2. Als SHA-2 zou worden verbroken, was de kans groot dat BLAKE ook zou worden aangetast.
IPsec en OpenVPN hebben vanwege hun ontwerp geen SipHash nodig. Dus het enige dat momenteel niet met hen kan worden gebruikt, is BLAKE2, en dat is alleen totdat het is gestandaardiseerd. Dit is geen groot nadeel, omdat VPN's HMAC gebruiken om integriteit te creëren, wat zelfs in combinatie met MD5 als een sterke oplossing wordt beschouwd.
Dus ik kwam tot de conclusie dat bijna dezelfde set cryptografische tools wordt gebruikt in alle VPN's. Daarom is WireGuard niet meer of minder veilig dan elk ander huidig product als het gaat om codering of de integriteit van verzonden gegevens.
Maar zelfs dit is niet het belangrijkste, wat de moeite waard is om op te letten volgens de officiële documentatie van het project. Het belangrijkste is tenslotte snelheid.
Is WireGuard sneller dan andere VPN-oplossingen?
Kortom: nee, niet sneller.
ChaCha20 is een stroomcijfer dat eenvoudiger te implementeren is in software. Het versleutelt bit voor bit. Blokprotocollen zoals AES versleutelen een blok met 128 bits per keer. Er zijn veel meer transistors nodig om hardware-ondersteuning te implementeren, dus grotere processors worden geleverd met AES-NI, een uitbreiding van de instructieset die enkele taken van het coderingsproces uitvoert om het te versnellen.
Er werd verwacht dat AES-NI nooit in smartphones zou komen [maar dat deed het — ca. per.]. Hiervoor is de ChaCha20 ontwikkeld als lichtgewicht, batterijbesparend alternatief. Daarom kan het als nieuws voor u komen dat elke smartphone die u vandaag kunt kopen een soort AES-versnelling heeft en sneller en met een lager stroomverbruik werkt met deze codering dan met ChaCha20.
Het is duidelijk dat zowat elke desktop-/serverprocessor die de afgelopen jaren is gekocht, AES-NI heeft.
Daarom verwacht ik dat AES in elk scenario beter zal presteren dan ChaCha20. De officiële documentatie van WireGuard vermeldt dat ChaCha512-Poly20 met AVX1305 beter zal presteren dan AES-NI, maar deze uitbreiding van de instructieset zal alleen beschikbaar zijn op grotere CPU's, wat wederom niet zal helpen met kleinere en meer mobiele hardware, die altijd sneller zal zijn met AES - N.I.
Ik weet niet zeker of dit tijdens de ontwikkeling van WireGuard had kunnen worden voorzien, maar vandaag is het feit dat het alleen aan encryptie is vastgespijkerd al een nadeel dat de werking ervan misschien niet zo goed beïnvloedt.
Met IPsec kunt u vrij kiezen welke codering het beste is voor uw geval. En dat is natuurlijk nodig als je bijvoorbeeld 10 of meer gigabyte aan data wilt overzetten via een VPN-verbinding.
Integratieproblemen in Linux
Hoewel WireGuard heeft gekozen voor een modern encryptieprotocol, zorgt dit al voor veel problemen. En dus, in plaats van out-of-the-box te gebruiken wat door de kernel wordt ondersteund, is de integratie van WireGuard jarenlang vertraagd vanwege het ontbreken van deze primitieven in Linux.
Ik weet niet helemaal zeker wat de situatie is op andere besturingssystemen, maar het is waarschijnlijk niet veel anders dan op Linux.
Hoe ziet de werkelijkheid eruit?
Helaas kom ik elke keer dat een klant me vraagt om een VPN-verbinding voor ze op te zetten, tegen het probleem aan dat ze verouderde inloggegevens en codering gebruiken. 3DES in combinatie met MD5 is nog steeds gebruikelijk, net als AES-256 en SHA1. En hoewel dat laatste iets beter is, is dit niet iets dat anno 2020 moet worden gebruikt.
Voor sleuteluitwisseling altijd RSA wordt gebruikt - een trage maar redelijk veilige tool.
Mijn cliënten zijn verbonden met douaneautoriteiten en andere overheidsorganisaties en -instellingen, maar ook met grote bedrijven waarvan de namen over de hele wereld bekend zijn. Ze gebruiken allemaal een aanvraagformulier dat tientallen jaren geleden is gemaakt en de mogelijkheid om SHA-512 te gebruiken is simpelweg nooit toegevoegd. Ik kan niet zeggen dat het op de een of andere manier duidelijk de technologische vooruitgang beïnvloedt, maar het vertraagt duidelijk het bedrijfsproces.
Het doet me pijn om dit te zien, omdat IPsec al sinds 2005 elliptische krommen ondersteunt. Curve25519 is ook nieuwer en beschikbaar voor gebruik. Er zijn ook alternatieven voor AES zoals Camellia en ChaCha20, maar die worden uiteraard niet allemaal ondersteund door grote leveranciers zoals Cisco en anderen.
En daar maken mensen misbruik van. Er zijn veel Cisco-kits, er zijn veel kits die zijn ontworpen om met Cisco te werken. Ze zijn marktleiders in dit segment en zijn niet erg geïnteresseerd in enige vorm van innovatie.
Ja, de situatie [in het zakelijke segment] is verschrikkelijk, maar we zullen geen veranderingen zien vanwege WireGuard. Leveranciers zullen waarschijnlijk nooit prestatieproblemen zien met de tooling en encryptie die ze al gebruiken, zullen geen problemen zien met IKEv2, en dus zijn ze niet op zoek naar alternatieven.
Heeft u er in het algemeen ooit aan gedacht om Cisco in de steek te laten?
Benchmarks
En laten we nu verder gaan met de benchmarks uit de WireGuard-documentatie. Hoewel deze [documentatie] geen wetenschappelijk artikel is, verwachtte ik toch dat de ontwikkelaars een meer wetenschappelijke benadering zouden kiezen, of een wetenschappelijke benadering als referentie zouden gebruiken. Alle benchmarks zijn nutteloos als ze niet kunnen worden gereproduceerd, en nog meer nutteloos als ze in het laboratorium zijn verkregen.
In de Linux-build van WireGuard profiteert het van het gebruik van GSO - Generic Segmentation Offloading. Dankzij hem creëert de klant een enorm pakket van 64 kilobyte en versleutelt / ontsleutelt dit in één keer. Aldus worden de kosten van het aanroepen en implementeren van cryptografische operaties verlaagd. Als u de doorvoer van uw VPN-verbinding wilt maximaliseren, is dit een goed idee.
Maar zoals gewoonlijk is de realiteit niet zo eenvoudig. Om zo'n groot pakket naar een netwerkadapter te sturen, moet het in veel kleinere pakketten worden geknipt. De normale verzendgrootte is 1500 bytes. Dat wil zeggen, onze gigant van 64 kilobyte zal worden verdeeld in 45 pakketten (1240 bytes aan informatie en 20 bytes van de IP-header). Daarna zullen ze een tijdje het werk van de netwerkadapter volledig blokkeren, omdat ze samen en in één keer moeten worden verzonden. Dit leidt tot een prioriteitssprong en pakketten zoals bijvoorbeeld VoIP komen in de wachtrij te staan.
De hoge doorvoer die WireGuard zo stoutmoedig beweert, wordt dus bereikt ten koste van het vertragen van het netwerken van andere applicaties. En het WireGuard-team is dat al dit is mijn conclusie.
Maar laten we verder gaan.
Volgens de benchmarks in de technische documentatie laat de verbinding een doorvoer zien van 1011 Mbps.
Indrukwekkend.
Dit is vooral indrukwekkend vanwege het feit dat de maximale theoretische doorvoer van een enkele Gigabit Ethernet-verbinding 966 Mbps is met 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 de WireGuard zelf. Er is nog een IP-header in het ingekapselde pakket en nog een in TCP voor 20 bytes. Dus waar komt deze extra bandbreedte vandaan?
Met enorme frames en de voordelen van GSO waar we het hierboven over hadden, zou het theoretische maximum voor een framegrootte van 9000 bytes 1014 Mbps zijn. Gewoonlijk is een dergelijke doorvoer in werkelijkheid onbereikbaar, omdat het gepaard gaat met grote moeilijkheden. Ik kan dus alleen maar aannemen dat de test is uitgevoerd met nog dikkere extra grote frames van 64 kilobytes met een theoretisch maximum van 1023 Mbps, wat alleen door sommige netwerkadapters wordt ondersteund. Maar dit is absoluut niet toepasbaar in reële omstandigheden, of kan alleen worden gebruikt tussen twee direct verbonden stations, uitsluitend binnen de testbank.
Maar aangezien de VPN-tunnel tussen twee hosts wordt doorgestuurd via een internetverbinding die helemaal geen jumboframes ondersteunt, kan het behaalde resultaat op de bank niet als maatstaf worden gebruikt. Dit is gewoon een onrealistische laboratoriumprestatie die onmogelijk en niet toepasbaar is in echte gevechtsomstandigheden.
Zelfs als ik in het datacenter zat, kon ik geen frames groter dan 9000 bytes overdragen.
Het criterium van toepasbaarheid in het echte leven wordt absoluut geschonden en, zoals ik denk, heeft de auteur van de uitgevoerde "meting" zichzelf om voor de hand liggende redenen ernstig in diskrediet gebracht.
Laatste sprankje hoop
Op de website van WireGuard wordt veel gesproken over containers en wordt duidelijk waar die eigenlijk voor bedoeld zijn.
Een eenvoudige en snelle VPN die geen configuratie vereist en kan worden geïmplementeerd en geconfigureerd met enorme orkestratietools zoals Amazon in hun cloud heeft. Amazon gebruikt met name de nieuwste hardwarefuncties die ik eerder noemde, zoals de AVX512. Dit wordt gedaan om het werk te versnellen en niet gebonden te zijn aan x86 of een andere architectuur.
Ze optimaliseren de doorvoer en pakketten groter dan 9000 bytes - dit zullen enorme ingekapselde frames zijn voor containers om met elkaar te communiceren, of voor back-upoperaties, het maken van snapshots of het inzetten van dezelfde containers. Zelfs dynamische IP-adressen hebben op geen enkele manier invloed op de werking van WireGuard in het geval van het scenario dat ik heb beschreven.
Goed gespeeld. Briljante implementatie en zeer dun, bijna referentieprotocol.
Maar het past gewoon niet in een wereld buiten een datacenter dat je volledig onder controle hebt. Als u het risico neemt en WireGuard gaat gebruiken, zult u voortdurend compromissen moeten sluiten bij het ontwerp en de implementatie van het coderingsprotocol.
Uitgang
Ik kan gemakkelijk concluderen dat WireGuard nog niet klaar is.
Het werd opgevat als een lichtgewicht en snelle oplossing voor een aantal problemen met bestaande oplossingen. Helaas heeft hij omwille van deze oplossingen veel functies opgeofferd die voor de meeste gebruikers relevant zullen zijn. Daarom kan het IPsec of OpenVPN niet vervangen.
Om ervoor te zorgen dat WireGuard concurrerend wordt, moet het ten minste een IP-adresinstelling en een routing- en DNS-configuratie toevoegen. Dit is duidelijk waar gecodeerde kanalen voor zijn.
Beveiliging is mijn topprioriteit en op dit moment heb ik geen reden om aan te nemen dat IKE of TLS op de een of andere manier gecompromitteerd of verbroken is. Moderne codering wordt in beide ondersteund en ze zijn bewezen door tientallen jaren gebruik. Dat iets nieuwer is, wil niet zeggen dat het beter is.
Interoperabiliteit is uiterst belangrijk wanneer u communiceert met derden wiens stations u niet beheert. IPsec is de de facto standaard en wordt bijna overal ondersteund. En hij werkt. En hoe het er ook uitziet, in theorie is WireGuard in de toekomst mogelijk niet compatibel, zelfs niet met verschillende versies van zichzelf.
Elke cryptografische beveiliging wordt vroeg of laat verbroken en moet daarom worden vervangen of bijgewerkt.
Al deze feiten ontkennen en blindelings WireGuard willen gebruiken om je iPhone met je thuiswerkstation te verbinden, is slechts een masterclass om je kop in het zand te steken.
Bron: www.habr.com