På det seneste har WireGuard tiltrukket sig stor opmærksomhed; det er faktisk den nye 'stjerne' blandt VPN. Men er det virkelig så godt, som det ser ud til? Jeg vil gerne diskutere nogle observationer og se nærmere på implementeringen af WireGuard for at forklare, hvorfor det ikke er en løsning, der vil erstatte IPsec eller OpenVPN.
I denne artikel vil jeg gerne aflive nogle myter [omkring WireGuard]. Ja, der vil være meget at læse, så hvis du ikke allerede har brygget en kop te eller kaffe, er det nu tid til det. Jeg vil også gerne takke Peter for at korrekturlæse mine kaotiske tanker.
Jeg har ikke til hensigt at diskreditere udviklerne af WireGuard, eller nedgøre deres indsats eller ideer. Deres produkt fungerer, men jeg mener personligt, at det bliver præsenteret helt forkert — det præsenteres som en erstatning for IPsec og OpenVPN, som der i virkeligheden ikke eksisterer lige nu.
Som en bemærkning skal det tilføjes, at ansvaret for denne positionering af WireGuard ligger hos medierne, der har dækket det, og ikke selve projektet eller dets skabere.
På det seneste har der ikke været for mange gode nyheder om Linux-kernen. Vi har fået fortalt om frygtelige sårbarheder i processoren, der blev udbedret på softwaremæssig måde, og Linus Torvalds har talt om det på en alt for grov og kedelig måde, med et utilitaristisk developer-sprog. Planlæggere eller netværksstacken i nulniveauet er heller ikke ligefrem klare emner for glansmagasiner. Og så dukker WireGuard op.
På papiret lyder det fantastisk: en spændende ny teknologi.
WireGuard’s tekniske dokumentation
Denne artikel er baseret på den officielle dokumentation for WireGuard, som er skrevet af Jason Donenfeld. Her forklarer han konceptet, målet og den tekniske implementering af [WireGuard] i Linux-kernen.
Den første sætning lyder:
WireGuard […] stræber efter at erstatte både IPsec i de fleste anvendelsesscenarier og andre populære løsninger baseret på brugerland og/eller TLS, såsom OpenVPN, samtidig med at det er et mere sikkert, effektivt og brugervenligt [værktøj].
Selvfølgelig er den største fordel ved alle nye teknologier deres simplicitet [i forhold til forgængerne]. Men en VPN skal også være effektiv og sikker.
Og hvad så?
Hvis du siger, at du ikke har brug for dette fra [VPN], så kan vi stoppe læsningen her. Men jeg vil bemærke, at sådanne opgaver stilles til enhver anden tunneling-teknologi.
Det mest interessante i det ovenstående citat ligger i ordene "i de fleste tilfælde", som avisen åbenbart har ignoreret. Og her er vi, hvor vi befinder os på grund af det kaos, der er skabt af denne forsømmelighed — i denne artikel.
Vil WireGuard erstatte min [IPsec] VPN-forbindelse mellem steder?
Nej. Der er simpelthen ingen chance for, at store leverandører som Cisco, Juniper og andre vil tage WireGuard til deres produkter. De hopper ikke ind i forbipasserende tog, hvis der ikke er en stor nødvendighed for det. Senere vil jeg forklare nogle af grundene til, at de sandsynligvis ikke vil kunne implementere WireGuard i deres produkter, selvom de ønskede det.
Vil WireGuard overføre min RoadWarrior fra bærbar til datacenter?
Nej. Lige nu er der mange vigtige funktioner, der ikke er implementeret i WireGuard, så det kan gøre noget lignende. For eksempel kan det ikke bruge dynamiske IP-adresser på tunnelsiden, og kun dette ødelægger hele scenariet for brugen af produktet.
IPFire bruges ofte til billige internetkanaler, for eksempel til DSL eller kabelforbindelse. Det giver mening for små eller mellemstore virksomheder, der ikke har brug for hurtig fibernet. [Bemærkning fra oversætteren: Husk, at Rusland og nogle CIS-lande ligger langt foran Europa og USA, når det kommer til forbindelser, fordi vi begyndte at opbygge vores netværk meget senere, og med introduktionen af Ethernet og fibernet som standard har det været lettere for os at omstille os. I de samme EU-lande eller USA er xDSL bredbånd med hastigheder på 3-5 Mbit/s stadig den generelle norm, mens en fibernetforbindelse koster urimelige summer efter vores målestok. Derfor taler forfatteren i artiklen om DSL- eller kabelforbindelser som normale og ikke som en forældet teknologi.] Men DSL, kabel, LTE (og andre trådløse adgangsmetoder) har dynamiske IP-adresser. Selvfølgelig ændrer de sig ikke ofte, men de ændrer sig stadig.
Der er et underprojekt, der hedder «wg-dynamic», som tilføjer en demonstrativ brugerflade for at overvinde denne mangel. Et stort problem med det brugerforløb, der er beskrevet ovenfor, er forværringen af situationen med dynamisk IPv6-adressering.
Set fra distributørens synspunkt ser det ikke særlig godt ud. Et af målene med udviklingen var at bevare enkelheden og renheden af protokollen.
Desværre er det hele faktisk blevet for enkelt og primitivt, så vi må bruge ekstra software for at gøre hele konstruktionen levedygtig i en reel driftsituation.
Er WireGuard så nemt at bruge?
Ikke endnu. Jeg siger ikke, at WireGuard aldrig vil blive et godt alternativ til at oprette en tunnel mellem to punkter, men lige nu er det kun en alfa-version af det produkt, det skal blive.
Men hvad laver det så egentlig? Er IPsec virkelig meget mere kompliceret at anvende?
Åbenbart ikke. IPsec-udbyderen har tænkt på dette problem og leverer sit produkt sammen med et interface, f.eks. med IPFire.
For at konfigurere en VPN-tunnel via IPsec skal du angive fem datasæt i konfigurationen: din egen offentlige IP-adresse, den offentlige IP-adresse på modtageren, de subnets, du ønsker at offentliggøre via denne VPN-forbindelse, og en pre-shared nøgle. Dette gør, at VPN'en kan konfigureres på få minutter, og den er kompatibel med enhver leverandør.
Desværre er der nogle undtagelser i denne historie. Enhver, der har forsøgt at oprette en VPN-tunnel gennem IPsec til en maskine på OpenBSD, ved, hvad jeg taler om. Der er et par andre smertefulde eksempler, men faktisk er der langt mere positiv praksis med brugen af IPsec.
Om kompleksiteten af protokollen
Den endelige forbruger skal ikke bekymre sig om protokollens kompleksitet.
Hvis vi levede i en verden, hvor det var en ægte bekymring for brugeren, ville vi længe være blevet kvitt SIP, H.323, FTP og andre protokoller, der er mere end ti år gamle, og som ikke fungerer godt med NAT.
Der er grunde til, at IPsec er mere kompliceret end WireGuard: det gør langt flere ting. For eksempel bruger det brugergodkendelse med login/password eller SIM-kort med EAP. Den har udvidede muligheder for at tilføje nye kryptografiske primtaler.
Og det har WireGuard ikke.
Og det betyder, at WireGuard på et tidspunkt vil bryde ned, fordi en af de kryptografiske primativer vil svækkes eller blive totalt kompromitteret. Forfatteren af teknisk dokumentation nævner det sådan her:
Det skal bemærkes, at WireGuard er kryptografisk selvsikker. Den mangler bevidst fleksibilitet med hensyn til cipher og protokoller. Hvis der opdages alvorlige sårbarheder i de underliggende primativer, skal alle endepunkter opdateres. Som man kan se fra den løbende strøm af SSL/TLS sårbarheder, er fleksibiliteten ved kryptering vokset kolossalt.
Den sidste sætning er helt korrekt.
At nå til enighed om, hvilken kryptering der skal anvendes, gør protokoller som IKE og TLS mere end komplekse. For komplekse? Ja, der opstår sårbarheder i TLS/SSL ret ofte, og der er ingen alternative løsninger.
Om at ignorere reelle problemer
Forestil dig, at du har en VPN-server med 200 aktive klienter spredt over hele verden. Det er et ganske standard brugsscenarie. Hvis du er nødt til at ændre krypteringen, skal du distribuere opdateringen til alle kopier af WireGuard på disse bærbare computere, smartphones osv. Samtidig distribuere. Det er bogstaveligt talt umuligt. Administratorer, der forsøger at gøre dette, vil bruge måneder på at udrulle de nødvendige konfigurationer, og for de fleste virksomheder vil det bogstaveligt talt tage år at gennemføre en sådan opgave.
IPsec og OpenVPN tilbyder en funktion til forhandling af cipher. Derfor vil det en tid, efter at du aktiverer det nye krypteringsstandard, også fortsat fungere med det gamle. Derved kan de nuværende klienter opgradere til den nye version. Når opdateringen er rullet ud, slukker du blot for den sårbare kryptering. Og så er det! Færdig! Du er fantastisk! Og kunderne bemærker det slet ikke.
Dette er faktisk et meget almindeligt scenarie for store udrulninger, og selv OpenVPN oplever nogle vanskeligheder med dette. Tilbageskompatibilitet er vigtig, og selvom du bruger svagere kryptering, bliver det for mange ikke en grund til at lukke virksomheden. For det vil føre til lammede arbejdsgange for hundredevis af kunder på grund af manglende evne til at udføre deres arbejde.
WireGuard-holdet har gjort deres protokol enklere, men helt uegnet for folk, der ikke har konstant kontrol over begge noder i deres tunnel. Efter min erfaring er det netop et sådant scenarie, der er mest almindeligt.
Kryptografi!
Men hvad er denne interessante nye kryptering, som WireGuard bruger?
WireGuard bruger Curve25519 til nøgleudveksling, ChaCha20 til kryptering og Poly1305 til dataautentifikation. Det arbejder også med SipHash til hash-nøgler og BLAKE2 til hashing.
ChaCha20-Poly1305 er standardiseret til IPsec og OpenVPN (gennem TLS).
Det er tydeligt, at udviklingen af Daniel Bernstein bruges meget ofte. BLAKE2 er efterfølgeren til BLAKE, der var finalist i SHA-3, men ikke vandt på grund af ligheden med SHA-2. Hvis SHA-2 blev brudt, skulle der være en stor sandsynlighed for, at BLAKE også ville blive kompromitteret.
IPsec og OpenVPN har ikke brug for SipHash på grund af deres design. Derfor er det eneste, der i øjeblikket ikke kan bruges med dem, BLAKE2, og kun indtil det er blevet standardiseret. Dette er ikke en stor ulempe, fordi VPN'er bruger HMAC til at skabe integritet, som anses for at være en stærk løsning, selv i kombination med MD5.
Så jeg konkluderede, at næsten det samme sæt kryptografiske værktøjer bruges i alle VPN'er. Derfor er WireGuard hverken mere eller mindre sikker end andre aktuelle produkter, når det kommer til kryptering eller integritet af de overførte data.
Men selv det er ikke det vigtigste, der bør bemærkes i henhold til den officielle dokumentation for projektet. Det vigtigste er hastigheden.
Er WireGuard hurtigere end andre VPN-løsninger?
Kort sagt: nej, ikke hurtigere.
ChaCha20 er en stream cipher, der er lettere at implementere i software. Den krypterer en bit ad gangen. Blockprotokoller, såsom AES, krypterer blokke på 128 bits ad gangen. For at implementere hardwareunderstøttelse kræves der meget flere transistorer, derfor leveres større processorer med AES-NI - en udvidelse af instruktionssættet, der udfører nogle krypteringsopgaver for at accelerere processen.
Det var forventet, at AES-NI aldrig ville komme ind i smartphones [men det gjorde det, — bem. red.]. Derfor blev ChaCha20 udviklet som et letvægts- og omkostningseffektivt alternativ, som skåner batteriets opladning. Så det kan være en overraskelse for dig, at enhver smartphone, du kan købe i dag, har noget form for acceleration til AES og fungerer med denne kryptering hurtigere og med lavere energiforbrug end med ChaCha20.
Det er klart, at næsten enhver processor til stationære PC’er / servere, der er købt de seneste par år, har AES-NI.
Derfor forventer jeg, at AES vil overgå ChaCha20 i enhver given situation. I den officielle dokumentation for WireGuard nævnes det, at ChaCha20-Poly1305 takket være AVX512 vil overgå AES-NI, men denne udvidelse af instruktionssættet vil kun være tilgængelig på større processorer, hvilket igen ikke vil hjælpe mindre og mobile enheder, som altid vil fungere hurtigere med AES-NI.
Jeg er ikke sikker på, om dette kunne være forudset under udviklingen af WireGuard, men i dag er den kendsgerning, at det er spikret til én kryptering, allerede en ulempe, som måske ikke vil have en god indflydelse på dets ydeevne.
IPsec giver frihed til at vælge, hvilken kryptering der passer bedst til dit tilfælde. Og selvfølgelig er dette nødvendigt, hvis du for eksempel ønsker at overføre 10 gigabyte eller mere data over en VPN-forbindelse.
Integrationsproblemer i Linux
Selvom WireGuard har valgt et moderne krypteringsprotokol, skaber det allerede en masse problemer. I stedet for at bruge det, der understøttes af kernen fra starten, er integrationen af WireGuard blevet forsinket i årevis på grund af manglen på disse primitive i Linux.
Jeg er ikke helt klar over, hvordan situationen er i andre operativsystemer, men det er sandsynligt, at den ikke adskiller sig meget fra situationen i Linux.
Hvordan ser virkeligheden ud?
Desværre, hver gang en klient beder mig om at sætte en VPN-forbindelse op for dem, står jeg over for emnet, at de bruger forældede legitimationsoplysninger og kryptering. 3DES i kombination med MD5 er stadig en udbredt praksis, ligesom AES-256 og SHA1. Og selvom sidstnævnte er en smule bedre — er det ikke noget, man bør bruge i 2020.
Til nøgleudveksling altid benyttes RSA — et langsomt, men tilstrækkeligt sikkert værktøj.
Mine kunder er forbundet med toldmyndighederne og andre statslige organer samt med store virksomheder, hvis navne er kendte verden over. Alle bruger en forespørgselsform, der blev oprettet for årtier siden, og muligheden for at bruge SHA-512 er aldrig blevet tilføjet. Jeg kan ikke sige, at det klart påvirker den teknologiske udvikling, men det er åbenlyst, at det bremser virksomhedens processer.
Det gør ondt at se, fordi IPsec siden omkring 2005 har understøttet elliptiske kurver. Curve25519 er også nyere og tilgængelig til brug. Der er også alternativer til AES, som Camellia og ChaCha20, men åbenlyst er ikke alle understøttet af store leverandører som Cisco og andre.
Og folk bruger det. Der er mange Cisco-udstyr, der er lavet til at arbejde med Cisco. De er markedsledere på dette område og er ikke så interesserede i innovation.
Ja, situationen [i virksomhedssektoren] er forfærdelig, men vi vil ikke se nogen ændringer på grund af WireGuard. Producenterne vil sandsynligvis aldrig identificere nogen præstationsproblemer med det allerede anvendte udstyr og kryptering, de vil ikke se problemer ved brug af IKEv2 — og derfor søger de ikke alternative løsninger.
Har du nogensinde tænkt på at opgive Cisco?
Benchmarktests
Og nu lad os gå videre til benchmarkresultaterne fra WireGuard-dokumentationen. Selvom dette [dokumentation] ikke er en videnskabelig artikel, forventede jeg stadig en mere videnskabelig tilgang fra udviklerne, eller at man brugte en videnskabelig metode som reference. Enhver benchmark er ubrugelig, hvis den ikke kan reproduceres, og endnu mere ubrugelig, når den er opnået under laboratorieforhold.
I WireGuard-implementeringen for Linux får den en fordel ved at bruge GSO — Generic Segmentation Offloading. Dette gør det muligt for klienten at skabe et enormt paket på 64 kilobyte og kryptere/afkryptere det i ét enkelt træk. Derved reduceres omkostningerne ved at kalde og implementere kryptografiske operationer. Hvis du ønsker at maksimere båndbredden i din VPN-forbindelse — så er dette en god idé.
Men som det ofte er, er virkeligheden ikke så simpel. At sende en så stor pakke til netværksadapteren kræver, at den skal opdeles i mange mindre pakker. Den typiske sendestørrelse er 1500 byte. Det vil sige, at vores gigant på 64 kilobyte vil blive delt op i 45 pakker (1240 byte information og 20 byte IP-header). Derefter vil de i et stykke tid fuldstændigt blokere netværksadapterens arbejde, fordi de skal sendes sammen og på én gang. Dette vil resultere i et prioritetsspring, hvilket betyder, at pakker som VoIP vil blive sat i kø.
Dermed opnås den høje båndbredde, som WireGuard praler med, ved at nedsætte netværksydelsen for andre applikationer. Og WireGuard-holdet er allerede funden min konklusion.
Men lad os komme videre.
Ifølge benchmarking i teknisk dokumentation viser forbindelsen en båndbredde på 1011 Mbit/s.
Imponerende.
Dette er især imponerende, fordi den maksimale teoretiske båndbredde for en gigabit Ethernet-forbindelse er 966 Mbit/s ved en pakkestørrelse på 1500 byte minus 20 byte for IP-headeren, 8 byte for UDP-headeren og 16 byte for WireGuard-headeren. Der er en ekstra IP-header i den indkapslede pakke og en anden på 20 byte i TCP. Hvordan opstod denne ekstra båndbredde?
Med store rammer og fordelene ved GSO, som vi har talt om ovenfor, vil den teoretiske maksimum ved en ramme på 9000 byte være 1014 Mbit/s. Normalt er denne båndbredde i praksis uopnåelig, da den er forbundet med store vanskeligheder. Så jeg kan kun antage, at testen blev udført ved brug af endnu større rammer, der overstiger 64 kilobyte med et teoretisk maksimum på 1023 Mbit/s, som kun understøttes af nogle netværksadaptere. Men dette er absolut ikke anvendeligt under virkelige forhold, eller det kan kun bruges mellem to stationer, der er direkte forbundet, udelukkende i rammerne af et testmiljø.
Men da VPN-tunnelen etableres mellem to værter via en internetforbindelse, der slet ikke understøtter store rammer, kan det opnåede resultat på standen ikke accepteres som et benchmark. Det er simpelthen en urealistisk laboratoriedestination, der ikke er muligt og ikke anvendeligt under reelle kampforhold.
Selv når jeg sidder i datacenteret, ville jeg ikke kunne overføre rammer større end 9000 byte.
Kritéret for anvendelighed i det virkelige liv er absolut krænkede, og som jeg ser det, har forfatteren af den udførte 'måling' alvorligt discrediteret sig selv af åbenlyse årsager.
Sidste skær af håb
På WireGuard-sitet tales der meget om containere og det bliver klart, hvad det egentlig er designet til.
En simpel og hurtig VPN, der ikke kræver opsætning og kan implementeres og konfigureres med massive orkestreringsværktøjer, såsom dem fra Amazon i deres sky. Specifikt bruger Amazon de nyeste hardwarefunktioner, som jeg nævnte tidligere, for eksempel — AVX512. Dette gøres for at accelerere ydeevnen og ikke være bundet til x86 eller nogen anden arkitektur.
De optimerer båndbredde og pakker, der overstiger 9000 byte — dette vil resultere i enorme indkapslede rammer til kommunikation mellem containere, eller til backup-operationer, snapshotting eller udrulning af disse containere. Selv dynamiske IP-adresser vil ikke påvirke WireGuards funktion i det scenarie, jeg har beskrevet.
Godt spillet. Strålende implementering og en meget fin, næsten benchmark-protokol.
Men den passer simpelthen ikke til verden udenfor det datacenter, du har fuld kontrol over. Hvis du dog vover dig og begynder at bruge WireGuard, skal du indgå konstante kompromiser i design og implementering af krypteringsprotokollen.
Output
Det er ikke svært for mig at konkludere, at WireGuard endnu ikke er klar.
Det blev tænkt som en lettere og hurtigere løsning på en række problemer i allerede eksisterende løsninger. Desværre ofrede det mange funktioner, der vil være relevante for de fleste brugere, i bestræbelserne på disse løsninger. Derfor kan det ikke erstatte IPsec eller OpenVPN.
For WireGuard to be competitive, it needs to add at least IP address settings, routing configuration, and DNS. It is clear that encrypted channels are necessary for this.
Security is my top priority, and I currently have no reason to believe that IKE or TLS are compromised or broken in any way. Modern encryption is supported by both, and they have been validated through decades of use. Just because something is newer doesn’t mean it’s better.
Functional compatibility is extremely important when connecting to third parties whose stations you do not control. IPsec is the de facto standard and is widely supported. And it works. As theoretical as it may seem, WireGuard could potentially be incompatible with different versions of itself in the future.
Any cryptographic protection will eventually be broken and thus needs to 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
