Hvorfor man ikke bør bruke WireGuard

I det siste har WireGuard fått mye oppmerksomhet, det er faktisk den nye «stjernen» blant VPN. Men er den så god som den ser ut til? Jeg vil gjerne diskutere noen observasjoner og se nærmere på implementeringen av WireGuard for å fortelle hvorfor den ikke er en løsning som vil erstatte IPsec eller OpenVPN.

I denne artikkelen vil jeg avkrefte noen myter [rundt WireGuard]. Ja, det blir en lang lesning, så hvis du ikke har laget deg en kopp te eller kaffe enda, er det på tide å gjøre det. Jeg vil også takke Peter for korrekturlesingen av mine kaotiske tanker.

Jeg har ikke som mål å diskreditere utviklerne av WireGuard eller undervurdere innsatsen deres. Deres produkt fungerer, men jeg mener personlig at det blir presentert som noe helt annet enn det faktisk er — presentert som en erstatning for IPsec og OpenVPN, noe som faktisk ikke eksisterer akkurat nå.

Som en merknad vil jeg legge til at ansvaret for denne posisjoneringen av WireGuard ligger hos mediene som har omtalt det, og ikke hos prosjektet eller skaperne.

I det siste har det ikke vært mange gode nyheter om Linux-kjernen. Vi har fått høre om grusomme sikkerhetshull i prosessorene som har blitt utbedret programvaremessig, og Linus Torvalds har snakket om dette på en altfor grov og kjedelig måte, med et utviklerspråk. Planleggeren eller nettverksstakken i nullnivå er heller ikke de mest forståelige temaene for glinsende magasiner. Og så dukker WireGuard opp.

På papiret høres alt bra ut: en spennende ny teknologi.

Men la oss se nærmere på den.

Den tekniske dokumentasjonen for WireGuard

This article is based on den offisielle dokumentasjonen til WireGuard, skrevet av Jason Donenfeld. Der forklarer han konseptet, målet og den tekniske implementeringen av [WireGuard] i Linux-kjernen.

Det første setningen lyder:

WireGuard […] søker å erstatte både IPsec i de fleste bruksområder og andre populære løsninger basert på brukerrom og/eller TLS, som OpenVPN, samtidig som den er et mer sikkert, effektivt og brukervennlig [verktøy].

Selvfølgelig er den største fordelen med alle nye teknologier deres enkelhet [sammenlignet med forgjengerne]. Men VPN må også være effektiv og sikker.

Og hva nå?

Hvis du sier at du ikke trenger dette fra [VPN], kan vi avslutte lesningen her. Jeg vil imidlertid påpeke at slike oppgaver stilles til enhver annen tunnelingteknologi.

Det mest interessante fra sitatet ovenfor ligger i ordene "i de fleste tilfeller", som presse selvsagt har ignorert. Og her er vi, der vi har havnet på grunn av det kaoset som denne uaktsomheten har skapt — i denne artikkelen.

Vil WireGuard erstatte min [IPsec] VPN-forbindelse mellom nettsteder?

Nei. Det er bare ingen sjanse for at store leverandører, som Cisco, Juniper og andre, vil ta i bruk WireGuard for sine produkter. De "hopper ikke på forbipasserende tog" med mindre det er et stort behov. Senere vil jeg forklare noen grunner til at de sannsynligvis ikke vil kunne implementere WireGuard i produktene sine, selv om de ønsket det.

Vil WireGuard flytte min RoadWarrior fra laptopen til datasenteret?

Nei. Akkurat nå har ikke WireGuard et stort antall viktige funksjoner som gjør at den kan gjøre noe lignende. For eksempel kan den ikke bruke dynamiske IP-adresser på serversiden av tunnelen, og bare dette ødelegger hele scenariet for denne typen bruk.

IPFire brukes ofte for billige internettkanaler, for eksempel for DSL eller kabeltilkobling. Dette gir mening for små eller mellomstore bedrifter som ikke har behov for rask fiberoptikk. [Notat fra oversetteren: husk at i kommunikasjonsplan er Russland og noen CIS-land langt foran Europa og USA, fordi vi begynte å bygge våre nettverk mye senere, og med ankomsten av Ethernet og fiberoptiske nettverk som standard, var det lettere for oss å omstille oss. I land som EU eller USA er xDSL bredbånd med hastigheter på 3-5 Mbps fortsatt en normalstandard, mens fiberoptisk tilkobling koster absurde beløp etter våre målestokker. Derfor snakker forfatteren av artikkelen om DSL eller kabeltilkobling som normen, ikke som et gammelt relikvie.] Men DSL, kabel, LTE (og andre trådløse tilgangsmåter) har dynamiske IP-adresser. Selvfølgelig endres de ikke ofte, men de endres fremdeles.

Det eksisterer et underprosjekt kalt «wg-dynamic», som legger til en brukerrom-demo for å overvinne denne mangelen. Et stort problem med brukerhistorien beskrevet ovenfor er forverringen av situasjonen med dynamisk IPv6-adressering.

Fra distributørens ståsted ser alt dette også ikke så bra ut. Et mål med utviklingen var å bevare enkelheten og renheten i protokollen.

Dessverre har alt dette faktisk blitt altfor enkelt og primitivt, så vi må bruke ekstra programvare for at hele denne strukturen skal være levedyktig under reelle driftsforhold.

Er WireGuard så enkelt å bruke?

Ikke enda. Jeg sier ikke at WireGuard aldri vil bli et godt alternativ for å tunnelere mellom to punkter, men for øyeblikket er det bare en alfa-versjon av produktet det bør være.

Men hva gjør den egentlig? Er IPsec virkelig så mye mer komplisert å bruke?

Åpenbart ikke. IPsec-leverandøren har tenkt på dette og tilbyr sitt produkt sammen med et grensesnitt, for eksempel med IPFire.

For å konfigurere en VPN-tunnel via IPsec trenger du fem datasett som må legges inn i konfigurasjonen: din egen offentlige IP-adresse, den offentlige IP-adressen til mottakeren, nettverkene du vil gjøre tilgjengelige gjennom denne VPN-tilkoblingen og en forhåndsdelt nøkkel. Slik sett kan VPN settes opp på noen minutter, og det er kompatibelt med hvilken som helst leverandør.

Dessverre finnes det noen unntak i denne historien. Alle som har prøvd å tunnelere en VPN-tilkobling via IPsec til en maskin med OpenBSD, vet hva jeg snakker om. Det finnes et par andre smertefulle eksempler, men det er faktisk langt flere positive erfaringer med bruk av IPsec.

Om kompleksiteten til protokollen

Sluttbrukeren skal ikke bekymre seg om protokollens kompleksitet.

Hvis vi levde i en verden der dette virkelig var en bekymring for brukeren, ville vi for lengst ha kvittet oss med SIP, H.323, FTP og andre protokoller laget for mer enn ti år siden som fungerer dårlig med NAT.

Det er grunner til at IPsec er mer komplisert enn WireGuard: det gjør mye flere ting. For eksempel, brukerautentisering med brukernavn/passord eller SIM-kort med EAP. Den har utvidet mulighet for å legge til nye kryptografiske primtall.

Og WireGuard har ikke det.

Og dette betyr at WireGuard på et tidspunkt vil svikte, fordi en av de kryptografiske primitive vil bli svekket eller helt kompromittert. Forfatteren av teknisk dokumentasjon sier dette slik:

Det er viktig å merke seg at WireGuard er kryptografisk selvtilfreds. Den mangler bevisst fleksibilitet i krypteringene og protokollene. Hvis det oppdages alvorlige hull i de underliggende primitive, vil alle endepunktene måtte oppdateres. Som vi ser fra det fortsatt pågående strømmen av sårbarheter i SSL/TLS, har fleksibiliteten til kryptering økt enormt.

Det siste utsagnet er helt riktig.

Å oppnå konsensus om hvilken kryptering som skal brukes, gjør protokoller som IKE og TLS over komplekse. For kompliserte? Ja, i TLS/SSL oppstår sårbarheter ganske ofte, og det finnes ingen alternativer.

Om å ignorere reelle problemer

Tenk deg at du har en VPN-server med 200 aktive klienter spredt over hele verden. Dette er et ganske standard bruksområde. Hvis du må endre kryptering, må du levere oppdateringen til alle kopiene av WireGuard på disse bærbare datamaskinene, smarttelefonene og så videre. Samtidigt å levere. Dette er bokstavelig talt umulig. Administratorer som prøver å gjøre dette vil trenge måneder for å rulle ut de nødvendige konfigurasjonene, og for mellomstore selskaper vil det bokstavelig talt ta år å gjennomføre slike tiltak.

IPsec og OpenVPN tilbyr funksjoner for forhandlingskryptering. Derfor vil det være en periode etter at du har aktivert ny kryptering, hvor den gamle fortsatt vil fungere. Takket være dette kan nåværende klienter oppdatere seg til den nye versjonen. Etter at oppdateringen er implementert, kan du enkelt deaktivere den sårbare krypteringen. Og alt! Ferdig! Du er fantastisk! Og kundene vil ikke engang legge merke til det.

Dette er faktisk et veldig vanlig tilfelle for store distribusjoner, og selv OpenVPN opplever noen utfordringer her. Bakoverkompatibilitet er viktig, og selv om du bruker svakere kryptering, fører det ikke til at mange stenger virksomheten. Fordi det ville føre til lammelse av arbeidet til hundrevis av kunder på grunn av manglende evne til å utføre jobben sin.

WireGuard-teamet har gjort protokollen enklere, men helt uegnet for personer som ikke har konstant kontroll over begge endepunktene i tunnelen sin. Etter min erfaring er akkurat dette scenariet det vanligste.

Kryptografi!

Men hva er dette interessante nye krypteringssystemet som WireGuard bruker?

WireGuard bruker Curve25519 for nøkkelutveksling, ChaCha20 for kryptering og Poly1305 for autentisering av data. Det samarbeider også med SipHash for hash-nøkler og BLAKE2 for hashing.

ChaCha20-Poly1305 er standardisert for IPsec og OpenVPN (gjennom TLS).

Det er tydelig at utviklingen av Daniel Bernsteins arbeid blir brukt veldig ofte. BLAKE2 er etterfølgeren til BLAKE, som var finalist i SHA-3, men ikke vant på grunn av likheten med SHA-2. Hvis SHA-2 skulle bli brutt, var det stor sjanse for at BLAKE også ville bli kompromittert.

IPsec og OpenVPN trenger ikke SipHash på grunn av sin design. Dermed er det eneste som for tiden ikke kan brukes med dem, BLAKE2, og det kun inntil det blir standardisert. Dette er ikke en stor ulempe, fordi VPN-er bruker HMAC for å skape integritet, noe som anses som en sterk løsning selv i kombinasjon med MD5.

Så jeg kom til den konklusjonen at nesten alle VPN-er bruker de samme kryptografiske verktøyene. Derfor er WireGuard ikke mer eller mindre sikkert enn andre aktuelle produkter når det gjelder kryptering eller integritet av overførte data.

Men selv ikke dette er det viktigste å merke seg ifølge prosjektets offisielle dokumentasjon. Det viktigste er hastighet.

Er WireGuard raskere enn andre VPN-løsninger?

Kort sagt: nei, ikke raskere.

ChaCha20 er en strøm-kryptering, som er lettere å implementere i programvare. Den krypterer ett bit av gangen. Blokkprotokoller som AES krypterer blokker på 128 bit av gangen. For å implementere maskinvarestøtte kreves det langt flere transistorer, derfor leveres større prosessorer med AES-NI — et utvidelsessett som utfører enkelte oppgaver i krypteringsprosessen for å akselerere det.

Det var forventet at AES-NI aldri skulle nå smarttelefoner [men det gjorde det, — anm. red.]. ChaCha20 ble utviklet som et lettvektsalternativ som sparer batteri. Derfor kan det være en nyhet for deg at hver smarttelefon du kan få tak i i dag har en eller annen form for akselerasjon for AES og jobber med denne krypteringen raskere og med mindre energiforbruk enn med ChaCha20.

Det er åpenbart at nesten alle stasjonære PC-/serverprosessorer kjøpt de siste par årene har AES-NI.

Derfor forventer jeg at AES vil overgå ChaCha20 i hvert eneste scenario. Den offisielle dokumentasjonen til WireGuard nevner at ChaCha20-Poly1305 vil overgå AES-NI takket være AVX512, men denne instruksjonssettutvidelsen vil kun være tilgjengelig på større prosessorer, noe som igjen ikke vil være til hjelp for mindre og mobile enheter, som alltid vil jobbe raskere med AES-NI.

Jeg er ikke sikker på om dette kunne bli forutsett under utviklingen av WireGuard, men i dag er det et faktum at den er låst til én kryptering — et trekk som kan påvirke ytelsen negativt.

IPsec lar deg fritt velge hvilken kryptering som passer best for ditt bruksområde. Og det er selvsagt nødvendig, hvis du for eksempel ønsker å overføre 10 GB eller mer med data over en VPN-tilkobling.

Integrasjonsproblemer i Linux

Selv om WireGuard valgte en moderne krypteringsprotokoll, har dette allerede ført til flere problemer. I stedet for å bruke det som er støttet av kjernen, har integrasjonen av WireGuard blitt forsinket i flere år på grunn av mangelen på disse primitive funksjonene i Linux.

Jeg er ikke helt oppdatert på hvordan situasjonen er i andre operativsystemer, men det er sannsynlig at den ikke avviker mye fra situasjonen med Linux.

Hvordan ser virkeligheten ut?

Dessverre, hver gang en kunde ber meg om å sette opp en VPN-tilkobling, møter jeg temaet om at de bruker utdaterte legitimasjoner og kryptering. 3DES kombinert med MD5 er fortsatt en vanlig praksis, akkurat som AES-256 og SHA1. Og selv om den siste er litt bedre — er det ikke noe man bør bruke i 2020.

For nøkkelutveksling altid brukes RSA — et sakte, men tilstrekkelig sikkert verktøy.

Mine kunder er knyttet til tollmyndigheter og andre statlige organer, samt store selskaper med navn kjent over hele verden. Alle bruker et forespørselsskjema som ble laget for flere tiår siden, og muligheten for å bruke SHA-512 har aldri blitt lagt til. Jeg kan ikke si at dette åpenbart påvirker den teknologiske utviklingen, men det er klart at det bremser bedriftsprosesser.

Det er smertefullt å se, fordi IPsec har støttet elliptiske kurver siden omtrent 2005. Curve25519 er også nyere og tilgjengelig for bruk. Det finnes også alternativer til AES, som Camellia og ChaCha20, men åpenbart støttes ikke alle av de store leverandørene som Cisco og lignende.

Og folk bruker det. Det finnes mange Cisco-sett, og flere sett laget for å fungere med Cisco. De er markedslederne i dette segmentet og er ikke særlig interessert i innovasjoner.

Ja, situasjonen [i bedriftssegmentet] er forferdelig, men vi vil ikke se noen endringer på grunn av WireGuard. Produsenter vil sannsynligvis aldri identifisere noen ytelsesproblemer med verktøyene og krypteringen de allerede bruker, og vil ikke oppdage problemer med IKEv2 — derfor leter de ikke etter alternativer.

Har du noen gang vurdert å gi slipp på Cisco?

Benchmark

Nå skal vi gå videre til benchmarkene fra WireGuard-dokumentasjonen. Selv om dette [dokumentasjonen] ikke er en vitenskapelig artikkel, forventet jeg mer vitenskapelighet fra utviklerne, eller det å bruke en vitenskapelig tilnærming som standard. Enhver benchmark er ubrukelig hvis den ikke kan reproduseres, og enda mer ubrukelig når den er utført under laboratorieforhold.

I WireGuard-byggingen for Linux får den fordelen ved å bruke GSO — Generic Segmentation Offloading. Dette lar klienten lage en enorm pakke på 64 kilobyte og kryptere/dekryptere den i ett enkelt trinn. Dermed reduseres kostnadene ved å påkalle og implementere kryptografiske operasjoner. Hvis du ønsker å maksimere båndbredden til VPN-tilkoblingen din, er dette en god idé.

Men, som det ofte er tilfelle, er ikke alt så enkelt i praksis. Sending av en så stor pakke til nettverksadapteren krever at den deles opp i mange mindre pakker. Den vanlige størrelsen på en sending er 1500 byte. Det vil si at vår gigant på 64 kilobyte vil bli delt opp i 45 pakker (1240 byte med informasjon og 20 byte IP-hode). Deretter vil de blokkere nettverksadapterens arbeid fullstendig i en periode, fordi de må sendes sammen og med en gang. Resultatet vil være en prioritetssjakk, og pakker som VoIP vil bli satt i ventekø.

Dermed oppnås den høye båndbredden som WireGuard så dristig hevder, ved å bremse nettverksarbeidet til andre applikasjoner. Og teamet bak WireGuard allerede bekreftet dette er min konklusjon.

Men la oss gå videre.

Ifølge benchmarkene i te dokumentasjonen viser forbindelsen en båndbredde på 1011 Mbit/s.

Imponerende.

Dette er spesielt imponerende med tanke på at den maksimale teoretiske båndbredden for en gigabit Ethernet-tilkobling er 966 Mbit/s ved en pakke størrelse på 1500 byte minus 20 byte for IP-hodet, 8 byte for UDP-hodet og 16 byte for WireGuard-hodet. Det er også et annet IP-hode i den inkapslede pakken og et annet på 20 byte i TCP. Så hvor kom denne ekstra båndbredden fra?

Med store rammer og fordelene ved GSO som vi har diskutert tidligere, vil den teoretiske maksimumet ved en ramme størrelse på 9000 byte være 1014 Mbit/s. Slike båndbredder er vanligvis ikke oppnåelige i virkeligheten, da det er knyttet til store utfordringer. Jeg kan derfor bare anta at testen ble utført med enda mer overdimensjonerte rammer med en størrelse over 64 kilobyte med en teoretisk maksimum på 1023 Mbit/s, noe som kun støttes av enkelte nettverksadaptere. Men dette er absolutt ikke praktisk i virkelige forhold, eller det kan kun brukes mellom to direktesammensatte stasjoner, utelukkende i et testoppsett.

Men since VPN-tunnelen passeres mellom to verter via en internettforbindelse som generelt ikke støtter store rammer, kan ikke resultatet oppnådd i testen betraktes som en standard. Dette er rett og slett en urealistisk laboratorieprestasjon som ikke kan anvendes under reelle forhold.

Selv om jeg skulle sitte i datasenteret, ville jeg ikke klart å overføre rammer større enn 9000 byte.

Kriteriet for anvendbarhet i virkeligheten er helt brutt, og jeg mener at forfatteren av den utførte «målingen» har diskredittert seg selv av åpenbare grunner.

Den siste gløden av håp

På WireGuard sin nettside snakkes det mye om containere, og det blir klart hva det egentlig er ment til.

En enkel og rask VPN som ikke krever oppsett og kan implementeres og konfigureres med masseverktøy for orkestrering, som for eksempel Amazon i deres sky. Spesielt bruker Amazon de nyeste maskinvarefunksjonene jeg nevnte tidligere, som AVX512. Dette gjøres for å akselerere ytelsen og unngå å være bundet til x86 eller noen annen arkitektur.

De optimaliserer båndbredden og pakkene som overskrider 9000 byte – dette blir enorme innkapslede rammer for kommunikasjon mellom containere, eller for operasjoner som sikkerhetskopiering, snapshotting eller deployment av disse containerne. Selv dynamiske IP-adresser vil ikke påvirke WireGuard sin funksjonalitet i det scenariet jeg beskrev.

Godt spilt. Glimrende implementering og et veldig subtilt, nesten standardisert protokoll.

Men det passer bare ikke for verden utenfor datasenteret du helt kontrollerer. Hvis du risikerer å bruke WireGuard, må du være forberedt på å ta kontinuerlige kompromisser i utviklingen og implementeringen av krypteringsprotokollen.

Utdata

Det er ikke vanskelig for meg å konkludere med at WireGuard fortsatt ikke er klart.

Det ble tenkt på som en lettvekts- og rask løsning på flere problemer med allerede eksisterende løsninger. Dessverre har det ofret mange funksjoner som ville vært relevante for de fleste brukere. Derfor kan det ikke erstatte IPsec eller OpenVPN.

For WireGuard to be competitive, it needs to add at least IP address configuration and routing and DNS setup. Clearly, this is why encrypted channels are necessary.

Security is my top priority, and I currently have no reason to believe that IKE or TLS are in any way compromised or broken. Modern encryption is supported in both, and they have been tested over decades of operation. Just because something is newer doesn’t mean it’s better.

Functional compatibility is extremely important when you connect with third parties whose stations you do not control. IPsec is de facto the standard and is supported almost universally. And it works. Regardless of how it may seem, theoretically, WireGuard could be incompatible with even its own different versions in the future.

Any cryptographic protection will eventually be broken and must therefore be replaced or updated.

Denying all these facts and blindly wanting to use WireGuard to connect your iPhone to your home workstation is simply a masterclass in burying your head in the sand.

Kilde: habr.com