Varför man inte bör använda WireGuard

På senare tid har WireGuard fått mycket uppmärksamhet; det är i grunden den nya "stjärnan" bland VPN. Men är det verkligen så bra som det verkar? Jag skulle vilja diskutera några observationer och granska implementeringen av WireGuard för att förklara varför det inte är en lösning som kan ersätta IPsec eller OpenVPN.

I den här artikeln skulle jag vilja avfärda några myter [kring WireGuard]. Ja, det kommer att ta tid att läsa så om du inte redan har gjort en kopp te eller kaffe, är det dags att göra det. Jag vill också tacka Peter för korrektur av mina kaotiska tankar.

Jag avser inte att misskreditera utvecklarna av WireGuard, undervärdera deras insatser eller idéer. Deras produkt fungerar, men jag anser personligen att den presenteras som något den inte är — som en ersättning för IPsec och OpenVPN, vilket egentligen inte existerar just nu.

Som en anmärkning vill jag tillägga att ansvaret för denna positionering av WireGuard faller på media som rapporterat om den, och inte på projektet eller dess skapare.

På senare tid har det inte kommit så många goda nyheter kring Linux-kärnan. Vi har fått höra om fruktansvärda sårbarheter i processorn som har åtgärdats programvarumässigt, och Linus Torvalds har beskrivit detta på ett för grovt och tråkigt sätt, med utvecklarens utilitaristiska språk. Schemaläggaren eller nätverksstacken av nollnivå är också inte särskilt begripliga ämnen för glansiga tidskrifter. Och här dyker WireGuard upp.

På papperet låter allt fantastiskt: en fascinerande ny teknik.

Men låt oss ta en närmare titt på den.

Teknisk dokumentation för WireGuard

Denna artikel är baserad på WireGuards officiella dokumentation, skriven av Jason Donenfeld. Där förklarar han konceptet, syftet och den tekniska implementeringen [WireGuard] i Linux-kärnan.

Det första stycket säger:

WireGuard […] strävar efter att ersätta både IPsec i de flesta användningsfall och andra populära lösningar som baseras på användarrum och/eller TLS, som OpenVPN, och är samtidigt ett mer säkert, prestandaoptimerat och användarvänligt [verktyg].

Självklart är den främsta fördelen med alla nya teknologier deras enkelhet [jämfört med föregångarna]. Men en VPN måste också vara effektiv och säker.

Och vad nu?

Om du säger att du inte behöver detta från [VPN], kan vi avsluta läsningen här. Jag vill dock påpeka att sådana uppgifter ställs på alla andra tunnelingteknologier.

Det mest intressanta i citatet ovan finns i orden "i de flesta fall", vilket media uppenbarligen har ignorerat. Och här är vi, där vi hamnat på grund av det kaos som skapats av denna vårdslöshet — i denna artikel.

Kommer WireGuard att ersätta min [IPsec] VPN-anslutning mellan webbplatser?

Nej. Det finns helt enkelt ingen chans att stora leverantörer som Cisco, Juniper och andra kommer att adoptera WireGuard för sina produkter. De "hoppar inte på passerande tåg" om det inte finns ett stort behov. Senare kommer jag att berätta om några anledningar till varför de sannolikt inte kommer att kunna integrera WireGuard i sina produkter, även om de skulle vilja.

Klarar WireGuard av att överföra min RoadWarrior från laptop till datacenter?

Nej. Just nu saknar WireGuard ett stort antal viktiga funktioner för att kunna göra något sådant. Till exempel kan den inte använda dynamiska IP-adresser på serverns tunnelsida, och bara detta bryter hela användningsscenariot för produkten.

IPFire används ofta för billiga internetkanaler, som DSL eller kabelanslutning. Det är vettigt för små eller medelstora företag som inte behöver snabb fiber. [Översättarens anmärkning: man ska inte glömma att Ryssland och vissa länder i CIS ligger långt före Europa och USA när det kommer till kommunikation, eftersom vi började bygga våra nätverk mycket senare och med införandet av Ethernet och fibernätverk som standard var det lättare för oss att anpassa oss. I länderna i EU eller USA är xDSL-bredband med hastigheter på 3-5 Mbit/s fortfarande en allmän norm, och fiberanslutningar kostar helt orimliga summor enligt våra mått. Därför pratar författaren om DSL eller kabelanslutning som en norm och inte som en gammal relik.] Dock har DSL, kabel, LTE (och andra trådlösa anslutningsmetoder) dynamiska IP-adresser. Visst, de förändras inte så ofta, men de förändras ändå.

Det finns ett underprojekt som heter "wg-dynamic", som lägger till en demon för användarutrymme för att åtgärda denna brist. Ett stort problem med användarscenariot som beskrivits ovan är förvärringen av situationen med dynamisk IPv6-adressering.

Ur distributörens perspektiv ser allt detta också mindre bra ut. Ett av målen med utvecklingen var att bevara enkelheten och renheten i protokollet.

Tyvärr har allt detta faktiskt blivit för enkelt och primitivt, så vi tvingas använda ytterligare mjukvara för att hela denna konstruktion ska vara livskraftig i praktisk användning.

Är det så enkelt att använda WireGuard?

Inte än. Jag säger inte att WireGuard aldrig kommer att vara ett bra alternativ för att skapa en tunnel mellan två punkter, men för tillfället är det bara en alfa-version av en produkt som det borde bli.

Men vad gör den egentligen? Är IPsec verkligen så mycket svårare att använda?

Uppenbarligen inte. Leverantören av IPsec har tänkt på detta och levererar sin produkt med ett gränssnitt, till exempel med IPFire.

För att konfigurera en VPN-tunnel via IPsec behöver du fem uppsättningar data som måste fyllas i konfigurationen: din egen offentliga IP-adress, den offentliga IP-adressen för mottagarsidan, de subnät som du vill göra tillgängliga via denna VPN-anslutning och en fördelad nyckel. Således kan VPN konfigureras på några minuter och den är kompatibel med alla leverantörer.

Tyvärr finns det några undantag i denna historia. Alla som har försökt skapa en VPN-tunnel via IPsec till en maskin på OpenBSD vet vad jag pratar om. Det finns några andra smärtsamma exempel, men det finns faktiskt mycket mer positiv praktik när det gäller att använda IPsec.

Om komplexiteten i protokollet

Slutkunden bör inte behöva oroa sig för komplexiteten i protokollet.

Om vi ​​bodde i en värld där detta var en verklig bekymmer för användare, skulle vi redan ha gjort oss av med SIP, H.323, FTP och andra protokoll som skapades för mer än tio år sedan och som fungerar dåligt med NAT.

Det finns skäl till att IPsec är mer komplext än WireGuard: det gör mycket fler saker. Till exempel autentisering av användare med användarnamn/lösenord eller SIM-kort med EAP. Den har utökad möjligheter att lägga till nya kryptografiska primitiva.

Och WireGuard har inte det.

Och det betyder att WireGuard kommer att gå sönder vid något tillfälle, eftersom en av de kryptografiska primitivarna kommer att försvagas eller bli helt komprometterad. Författaren av teknikdokumentationen säger detta så här:

Det är värt att notera att WireGuard är kryptografiskt självsäker. Den saknar avsiktligt flexibiliteten i algoritmer och protokoll. Om allvarliga sårbarheter upptäcks i de underliggande primitivarna, måste alla slutpunkter uppdateras. Som man kan se från det pågående flödet av sårbarheter i SLL/TLS har flexibiliteten i kryptering ökat kolossalt.

Den sista meningen är helt korrekt.

Att nå enighet om vilket kryptering som ska användas gör protokoll som IKE och TLS över komplicerade. För komplicerade? Ja, sårbarheter i TLS/SSL förekommer ganska ofta, och det finns inga alternativ.

Om att bortse från verkliga problem

Tänk dig att du har en VPN-server med 200 aktiva klienter spridda över hela världen. Det är ett ganska standardanvändningsscenario. Om du måste ändra kryptering, måste du distribuera en uppdatering till alla kopior av WireGuard på dessa bärbara datorer, smartphones osv. Samtidigt distribuera. Det är bokstavligen omöjligt. Administratörer som försöker göra detta kommer att behöva månader för att distribuera nödvändiga konfigurationer, och medelstora företag kommer bokstavligen att behöva år för att genomföra en sådan åtgärd.

IPsec och OpenVPN erbjuder funktionalitet för förhandling av krypteringar. Så en tid efter att du aktiverar den nya krypteringen kommer även den gamla att fungera. Tack vare detta kan nuvarande klienter uppgradera till den nya versionen. När uppdateringen har distribuerats, stänger du helt enkelt av den sårbara krypteringen. Och klart! Du är fantastisk! Klienterna kommer inte ens att märka det.

Detta är faktiskt ett mycket vanligt fall för stora distributioner, och även OpenVPN upplever vissa svårigheter med detta. Bakåtkompatibilitet är viktigt, och även om du använder svagare kryptering, blir det för många inte en anledning att stänga ner verksamheten. För det skulle leda till ett totalstopp för hundratals klienter på grund av oförmågan att utföra sitt arbete.

WireGuard-teamet har gjort sin protokoll enklare, men helt olämplig för personer som inte har konstant kontroll över båda noderna i sin tunnel. Utifrån min erfarenhet är just detta scenario det vanligaste.

Kryptografi!

Men vad är detta intressanta nya krypteringsmetod som WireGuard använder?

WireGuard använder Curve25519 för nyckelutbyte, ChaCha20 för kryptering och Poly1305 för dataintegritet. Det fungerar också med SipHash för hashnycklar och BLAKE2 för hashing.

ChaCha20-Poly1305 är standardiserat för IPsec och OpenVPN (via TLS).

Uppenbarligen används utvecklingen av Daniel Bernstein mycket ofta. BLAKE2 är efterföljaren till BLAKE, som var finalist i SHA-3, men inte vann på grund av dess likhet med SHA-2. Om SHA-2 skulle bli hackat, skulle det vara stor sannolikhet att även BLAKE skulle bli kompromenterat.

IPsec och OpenVPN behöver inte SipHash på grund av deras design. Så det enda som för närvarande inte kan användas med dem är BLAKE2, och det endast tills det standardiseras. Det är inte en stor nackdel, eftersom VPN använder HMAC för att skapa integritet, vilket anses vara en stark lösning även i kombination med MD5.

Så jag har kommit fram till att praktiskt taget samma uppsättning kryptografiska verktyg används i alla VPN. Därför är WireGuard varken mer eller mindre säkert än andra aktuella produkter när det kommer till kryptering eller integritet av de data som överförs.

Men även detta är inte det mest centrala att uppmärksamma enligt projektets officiella dokumentation. Det viktigaste är hastigheten.

Är WireGuard snabbare än andra VPN-lösningar?

För att sammanfatta: nej, inte snabbare.

ChaCha20 är en strömkryptering som är lättare att implementera i programvara. Den krypterar en bit i taget. Blockprotokoll, som AES, krypterar block på 128 bitar i taget. För att implementera hårdvarustöd krävs betydligt fler transistorer, varför större processorer ofta är utrustade med AES-NI — ett utvidgningsset som utför vissa uppgifter i krypteringsprocessen för att påskynda dem.

Det förväntades att AES-NI aldrig skulle nå smartphones [men det gjorde det, — anm. övers.]. För detta utvecklades ChaCha20 — som ett lätt och kostnadseffektivt alternativ som skonar batteriet. Därför kan det vara nytt för dig att varje smartphone som du kan köpa idag har något slags acceleration för AES och arbetar med denna kryptering snabbare och med mindre energiförbrukning än med ChaCha20.

Det är uppenbart att nästan varje processor för stationära datorer/serverar som köpts under de senaste åren har AES-NI.

Därför förväntar jag mig att AES överträffar ChaCha20 i varje enskilt scenario. I den officiella dokumentationen för WireGuard nämns det att tack vare AVX512 kommer ChaCha20-Poly1305 att överträffa AES-NI, men denna instruktionsuppsättning kommer endast att finnas tillgänglig på större processorer, vilket å sin sida inte hjälper med mindre och mobila enheter, som alltid kommer att fungera snabbare med AES-NI.

Jag är inte säker på om man kunde förutse detta vid utvecklingen av WireGuard, men idag är det ett faktum att det är fast förankrat i en kryptering — vilket redan är en nackdel som kan påverka dess funktion negativt.

IPsec gör det möjligt att fritt välja vilken kryptering som passar bäst för ditt fall. Och självklart är detta nödvändigt om du till exempel vill överföra 10 eller fler gigabyte data via en VPN-anslutning.

Integrationsproblem i Linux

Även om WireGuard har valt en modern krypteringsprotokoll, orsakar det redan en mängd problem. Och istället för att använda det som stöds av kärnan direkt, har integrationen av WireGuard skjutits upp i flera år på grund av bristen på dessa primitiva funktioner i Linux.

Jag är inte helt uppdaterad på hur situationen ser ut i andra operativsystem, men det är troligt att det inte skiljer sig mycket från situationen med Linux.

Hur ser verkligheten ut?

Tyvärr, varje gång en kund ber mig att konfigurera en VPN-anslutning, stöter jag på att de använder föråldrade uppgifter och kryptering. 3DES i kombination med MD5 är fortfarande en vanlig praxis, liksom AES-256 och SHA1. Och även om den sistnämnda är något bättre — är det inte något man ska använda under 2020.

För nyckelutbyte alltid används RSA — en långsam, men tillräckligt säker metod.

Mina kunder är kopplade till tullmyndigheter och andra statliga organ samt stora företag vars namn är kända världen över. Alla använder en begäran som skapades för flera decennier sedan, och möjligheten att använda SHA-512 har helt enkelt aldrig lagts till. Jag kan inte säga att detta på något sätt påverkar den teknologiska utvecklingen, men det är uppenbart att det saktar ner företagsprocesserna.

Det gör ont att se, eftersom IPsec har stöd för elliptiska kurvor sedan omkring 2005. Curve25519 är också nyare och tillgänglig för användning. Det finns även alternativ till AES, såsom Camellia och ChaCha20, men uppenbarligen stöds inte alla av stora leverantörer som Cisco och andra.

Och människor använder detta. Det finns många Cisco-paket, det finns många uppsättningar som skapats för att fungera med Cisco. De är marknadsledande inom detta segment och är inte särskilt intresserade av några innovationer.

Ja, situationen [i företagssegmentet] är fruktansvärd, men vi kommer inte att se några förändringar på grund av WireGuard. Tillverkarna kommer troligtvis aldrig att avslöja några prestandaproblem med det befintliga verktyg och kryptering som används, de kommer inte att se problem vid användning av IKEv2 – och därför letar de inte efter alternativ.

Har du någonsin tänkt på att överge Cisco?

Benchmarking

Och nu går vi vidare till prestandatest från WireGuards dokumentation. Även om denna [dokumentation] inte är en vetenskaplig artikel, förväntade jag mig ändå en mer vetenskaplig ansats från utvecklarna, eller att man använde en vetenskaplig metod som referens. Alla prestandatest är värdelösa om de inte kan reproduceras, och de är ännu mer värdelösa när de utförs under laboratorieförhållanden.

I WireGuard-versionen för Linux får den en fördel genom att använda GSO – Generic Segmentation Offloading. Tack vare detta kan klienten skapa ett stort paket på 64 kilobyte och kryptera/dekryptera det i ett enda steg. På så sätt minskar kostnaderna för att anropa och genomföra kryptografiska operationer. Om du vill maximera bandbredden på din VPN-anslutning – är detta en bra idé.

Men som vanligt är verkligheten inte så enkel. Att skicka en så stor paket till nätverksadaptern kräver att det delas upp i många mindre paket. Den vanliga storleken på en sändning är 1500 byte. Det innebär att vår jätte på 64 kilobyte kommer att delas upp i 45 paket (1240 byte information och 20 byte IP-header). Sedan kommer de att helt blockera nätverksadaptern under en tid, eftersom de måste skickas tillsammans och omedelbart. Slutresultatet blir att prioriteringen hoppar, och paket såsom VoIP kommer att sättas i kö.

Så, den höga bandbredd som WireGuard så djärvt hävdar, uppnås genom att sakta ner nätverksarbetet för andra applikationer. Och teamet bakom WireGuard redan bekräftade detta är min slutsats.

Men låt oss gå vidare.

Enligt benchmarking i teknisk dokumentation visar anslutningen en bandbredd på 1011 Mbit/s.

Imponerande.

Detta är särskilt imponerande eftersom den maximala teoretiska bandbredden för en gigabit Ethernet-anslutning är 966 Mbit/s med en paketstorlek på 1500 byte minus 20 byte för IP-headern, 8 byte för UDP-headern och 16 byte för WireGuard-headern. Det finns också en ytterligare IP-header i det inkapslade paketet och en annan på 20 byte i TCP. Så varifrån kom denna extra bandbredd?

Med stora ramar och fördelarna med GSO, som vi nämnde tidigare, kommer det teoretiska max vid en ramstorlek på 9000 byte att vara 1014 Mbit/s. Vanligtvis är sådan bandbredd i praktiken orealistisk, eftersom det är förenat med stora svårigheter. Därför kan jag bara anta att testet genomfördes med ännu större ramar som överskrider storleken på 64 kilobyte med ett teoretiskt max på 1023 Mbit/s, vilket bara stöds av vissa nätverksadaptrar. Men detta är helt orealistiskt under verkliga förhållanden, eller kan endast användas mellan två direkt anslutna stationer, enbart inom ramarna för en testmiljö.

Men eftersom VPN-tunneln körs mellan två värdar via en internetuppkoppling som i allmänhet inte stöder stora ramar, kan resultatet på testbänken inte accepteras som en standard. Det är helt enkelt en orealistisk laboratorieframgång som är omöjlig och inte tillämplig i verkliga stridsförhållanden.

Även om jag satt i datacentret skulle jag inte kunna skicka ramar som är större än 9000 byte.

Kriteriet för tillämplighet i verkligheten har helt enkelt brutits, och enligt min mening har författaren av den utförda "mätningen" allvarligt diskrediterat sig själv av uppenbara skäl.

Den sista strimman av hopp

På WireGuard-webbplatsen pratas det mycket om containrar, och det blir tydligt vad den faktiskt är avsedd för.

En enkel och snabb VPN som inte kräver installation och kan distribueras och konfigureras med massiva orkestreringsverktyg, som till exempel Amazons i deras moln. Specifikt använder Amazon de senaste hårdvarufunktionerna som jag nämnde tidigare, som AVX512. Detta görs för att påskynda arbetet och inte bli knuten till x86 eller någon annan arkitektur.

De optimerar bandbredden och paket som överstiger 9000 byte — detta resulterar i enorma inkapslade ramar för kommunikation mellan containrar eller för backupoperationer, skapande av snapshots, eller för att distribuera dessaContainrar. Även dynamiska IP-adresser kommer inte att påverka WireGuards funktion i det scenario jag beskrivit.

Bra spelat. En lysande implementering och en mycket subtil, nästan standardprotokoll.

Men det passar helt enkelt inte för världen utanför ett datacenter som helt kontrolleras av dig. Om du vågar och börjar använda WireGuard, kommer du att behöva göra ständiga kompromisser vid utveckling och implementation av krypteringsprotokollet.

Utdata

Det är inte svårt för mig att dra slutsatsen att WireGuard ännu inte är redo.

Det var tänkt som en lättviktig och snabb lösning på en rad problem med redan existerande lösningar. Tyvärr har det, i syfte att lösa dessa problem, offrat många funktioner som skulle vara relevanta för de flesta användare. Därför kan det inte ersätta IPsec eller OpenVPN.

För att WireGuard ska bli konkurrenskraftigt behöver det åtminstone lägga till stöd för IP-adresser och konfiguration av routing och DNS. Det är uppenbart att det är just därför vi behöver krypterade kanaler.

Säkerhet är min högsta prioritet, och jag har för närvarande ingen anledning att tro att IKE eller TLS har komprometterats eller brutits. Modern kryptering stöds i båda och har testats under årtionden av användning. Om något är nyare betyder det inte att det är bättre.

Funktionell kompatibilitet är extremt viktig när man kommunicerar med tredje parter vars stationer man inte kontrollerar. IPsec är de facto standard och stöds nästan överallt. Och det fungerar. Och hur det än ser ut, kan WireGuard i framtiden bli inkompatibelt även med olika versioner av sig själv.

All kryptografisk skyddsteknik bryts förr eller senare och måste därför bytas ut eller uppgraderas.

Att förneka alla dessa fakta och blint vilja använda WireGuard för att ansluta din iPhone till din hem-arbetsstation är helt enkelt en masterklass i att sätta huvudet i sanden.

Källa: habr.com