WireGuard har fået meget opmærksomhed på det seneste, faktisk er det den nye stjerne blandt VPN'er. Men er han så god, som han ser ud til? Jeg vil gerne diskutere nogle observationer og gennemgå implementeringen af WireGuard for at forklare, hvorfor det ikke er en løsning at erstatte IPsec eller OpenVPN.
I denne artikel vil jeg gerne aflive nogle af myterne [omkring WireGuard]. Ja, det vil tage lang tid at læse, så hvis du ikke har lavet dig en kop te eller kaffe, så er det på tide at gøre det. Jeg vil også gerne sige tak til Peter for at rette op på mine kaotiske tanker.
Jeg sætter mig ikke som mål at miskreditere udviklerne af WireGuard, devaluere deres indsats eller ideer. Deres produkt virker, men personligt synes jeg, at det præsenteres helt anderledes, end det egentlig er – det præsenteres som en erstatning for IPsec og OpenVPN, som faktisk simpelthen ikke eksisterer nu.
Som en bemærkning vil jeg gerne tilføje, at ansvaret for en sådan positionering af WireGuard ligger hos de medier, der talte om det, og ikke selve projektet eller dets skabere.
Der har ikke været mange gode nyheder om Linux-kernen på det seneste. Så vi fik at vide om processorens monstrøse sårbarheder, som blev udjævnet af software, og Linus Torvalds talte om det for groft og kedeligt på udviklerens utilitaristiske sprog. En skemalægger eller en netværksstack på nulniveau er heller ikke særlig klare emner for glossy magasiner. Og her kommer WireGuard.
På papiret lyder det hele fantastisk: en spændende ny teknologi.
Men lad os se lidt nærmere på det.
WireGuard hvidt papir
Denne artikel er baseret på skrevet af Jason Donenfeld. Der forklarer han konceptet, formålet og den tekniske implementering af [WireGuard] i Linux-kernen.
Den første sætning lyder:
WireGuard […] sigter mod at erstatte både IPsec i de fleste tilfælde og andre populære brugerrum og/eller TLS-baserede løsninger såsom OpenVPN, samtidig med at de er mere sikre, mere effektive og nemmere at bruge [værktøj].
Selvfølgelig er den største fordel ved alle nye teknologier deres lethed [sammenlignet med forgængere]. Men det burde en VPN også være effektivt og sikkert.
Så hvad er det næste?
Hvis du siger, at det ikke er det, du har brug for [fra en VPN], så kan du afslutte læsningen her. Jeg vil dog bemærke, at sådanne opgaver er sat til enhver anden tunnelteknologi.
Det mest interessante af ovenstående citat ligger i ordene "i de fleste tilfælde", som naturligvis blev ignoreret af pressen. Og så er vi der, hvor vi endte på grund af kaoset skabt af denne uagtsomhed - i denne artikel.
Vil WireGuard erstatte min [IPsec] site-to-site VPN?
Ingen. Der er simpelthen ingen chance for, at store leverandører som Cisco, Juniper og andre vil købe WireGuard til deres produkter. De "hopper ikke på forbipasserende tog" på farten, medmindre der er et stort behov for at gøre det. Senere vil jeg gennemgå nogle af grundene til, at de nok ikke vil kunne få deres WireGuard-produkter ombord, selvom de gerne ville.
Vil WireGuard tage min RoadWarrior fra min bærbare computer til datacentret?
Ingen. Lige nu har WireGuard ikke et stort antal vigtige funktioner implementeret for at kunne gøre noget som dette. For eksempel kan den ikke bruge dynamiske IP-adresser på tunnelserversiden, og dette alene bryder hele scenariet for sådan brug af produktet.
IPFire bruges ofte til billige internetforbindelser, såsom DSL- eller kabelforbindelser. Dette giver mening for små eller mellemstore virksomheder, der ikke har brug for hurtig fiber. [Note fra oversætteren: glem ikke, at med hensyn til kommunikation er Rusland og nogle SNG-lande langt foran Europa og USA, fordi vi begyndte at bygge vores netværk meget senere og med fremkomsten af Ethernet og fiberoptiske netværk som en standard, var det nemmere for os at genopbygge. I de samme lande i EU eller USA er xDSL bredbåndsadgang med en hastighed på 3-5 Mbps stadig den generelle norm, og en fiberoptisk forbindelse koster nogle urealistiske penge efter vores standarder. Derfor taler forfatteren af artiklen om DSL eller kabelforbindelse som normen og ikke oldtiden.] DSL, kabel, LTE (og andre trådløse adgangsmetoder) har dog dynamiske IP-adresser. Selvfølgelig ændrer de sig nogle gange ikke ofte, men de ændrer sig.
Der er et delprojekt, der hedder , som tilføjer en userspace-dæmon for at overvinde denne mangel. Et stort problem med brugerscenariet beskrevet ovenfor er forværringen af dynamisk IPv6-adressering.
Fra distributørens synspunkt ser alt dette heller ikke særlig godt ud. Et af designmålene var at holde protokollen enkel og ren.
Desværre er alt dette faktisk blevet for simpelt og primitivt, så vi er nødt til at bruge ekstra software, for at hele dette design er levedygtigt i reel brug.
Er WireGuard så nem at bruge?
Ikke endnu. Jeg siger ikke, at WireGuard aldrig vil være et godt alternativ til tunneling mellem to punkter, men indtil videre er det kun en alfaversion af det produkt, det skal være.
Men hvad gør han så egentlig? Er IPsec virkelig så meget sværere at vedligeholde?
Tydeligvis ikke. IPsec-leverandøren har tænkt på dette og sender deres produkt sammen med en grænseflade, såsom med IPFire.
For at konfigurere en VPN-tunnel over IPsec skal du bruge fem sæt data, som du skal indtaste i konfigurationen: din egen offentlige IP-adresse, den offentlige IP-adresse på den modtagende part, de undernet, du vil gøre offentlige via denne VPN-forbindelse og foruddelte nøgle. VPN er således sat op inden for få minutter og er kompatibel med enhver leverandør.
Desværre er der nogle få undtagelser fra denne historie. Enhver, der har forsøgt at tunnelere over IPsec til en OpenBSD-maskine, ved, hvad jeg taler om. Der er et par mere smertefulde eksempler, men faktisk er der mange, mange flere god praksis for at bruge IPsec.
Om protokolkompleksitet
Slutbrugeren behøver ikke at bekymre sig om kompleksiteten af protokollen.
Hvis vi levede i en verden, hvor dette var en reel bekymring for brugeren, så ville vi for længst være sluppet af med SIP, H.323, FTP og andre protokoller skabt for mere end ti år siden, som ikke fungerer godt med NAT.
Der er grunde til, at IPsec er mere kompleks end WireGuard: det gør mange flere ting. For eksempel brugergodkendelse ved hjælp af et login/adgangskode eller et SIM-kort med EAP. Det har en udvidet mulighed for at tilføje nye .
Og det har WireGuard ikke.
Og det betyder, at WireGuard vil gå i stykker på et tidspunkt, fordi en af de kryptografiske primitiver vil svækkes eller blive fuldstændig kompromitteret. Forfatteren af den tekniske dokumentation siger dette:
Det er værd at bemærke, at WireGuard er kryptografisk opfattet. Det mangler bevidst fleksibiliteten af ciphers og protokoller. Hvis der findes alvorlige huller i underliggende primitiver, skal alle endepunkter opdateres. Som du kan se fra den igangværende strøm af SLL/TLS-sårbarheder, er krypteringsfleksibiliteten nu steget enormt.
Den sidste sætning er helt korrekt.
At opnå konsensus om, hvilken kryptering der skal bruges, gør protokoller som IKE og TLS mere kompleks. For indviklet? Ja, sårbarheder er ret almindelige i TLS/SSL, og der er intet alternativ til dem.
Om at ignorere reelle problemer
Forestil dig, at du har en VPN-server med 200 kampklienter et eller andet sted rundt om i verden. Dette er en ret standard use case. Hvis du skal ændre krypteringen, skal du levere opdateringen til alle kopier af WireGuard på disse bærbare computere, smartphones og så videre. Samtidigt aflevere. Det er bogstaveligt talt umuligt. Administratorer, der forsøger at gøre dette, vil tage måneder at implementere de nødvendige konfigurationer, og det vil bogstaveligt talt tage et mellemstort firma år at gennemføre en sådan begivenhed.
IPsec og OpenVPN tilbyder en chifferforhandlingsfunktion. Derfor vil den gamle også virke i nogen tid, hvorefter du slår den nye kryptering til. Dette vil give nuværende kunder mulighed for at opgradere til den nye version. Efter opdateringen er rullet ud, slår du blot den sårbare kryptering fra. Og det er det! Parat! du er smuk! Kunderne vil ikke engang bemærke det.
Dette er faktisk et meget almindeligt tilfælde for store implementeringer, og selv OpenVPN har nogle problemer med dette. Bagudkompatibilitet er vigtig, og selvom du bruger svagere kryptering, er dette for mange ikke en grund til at lukke en virksomhed. Fordi det vil lamme hundredvis af kunders arbejde på grund af manglende evne til at udføre deres arbejde.
WireGuard-teamet har gjort deres protokol enklere, men fuldstændig ubrugelig for folk, der ikke har konstant kontrol over begge peers i deres tunnel. Efter min erfaring er dette det mest almindelige scenarie.
Kryptografi!
Men hvad er denne interessante nye kryptering, som WireGuard bruger?
WireGuard bruger Curve25519 til nøgleudveksling, ChaCha20 til kryptering og Poly1305 til datagodkendelse. Det fungerer også med SipHash til hash-nøgler og BLAKE2 til hash.
ChaCha20-Poly1305 er standardiseret til IPsec og OpenVPN (over TLS).
Det er indlysende, at udviklingen af Daniel Bernstein bruges meget ofte. BLAKE2 er efterfølgeren til BLAKE, en SHA-3 finalist, der ikke vandt på grund af sin lighed med SHA-2. Hvis SHA-2 skulle gå i stykker, var der en god chance for, at BLAKE også ville blive kompromitteret.
IPsec og OpenVPN har ikke brug for SipHash på grund af deres design. Så det eneste, der i øjeblikket ikke kan bruges med dem, er BLAKE2, og det er kun indtil det er standardiseret. Dette er ikke en stor ulempe, fordi VPN'er bruger HMAC til at skabe integritet, hvilket betragtes som en stærk løsning selv i forbindelse med MD5.
Så jeg kom til den konklusion, 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 noget andet nuværende produkt, når det kommer til kryptering eller integriteten af transmitterede data.
Men selv dette er ikke det vigtigste, som er værd at være opmærksom på ifølge den officielle dokumentation for projektet. Det vigtigste er trods alt hastighed.
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. Blokprotokoller som AES krypterer en blok 128 bit ad gangen. Der kræves meget flere transistorer for at implementere hardwaresupport, så større processorer kommer med AES-NI, en instruktionssætudvidelse, der udfører nogle af krypteringsprocessens opgaver for at fremskynde den.
Det var forventet, at AES-NI aldrig ville komme ind i smartphones [men det gjorde det - ca. om.]. Til dette blev ChaCha20 udviklet som et let, batteribesparende alternativ. Derfor kan det komme som en nyhed for dig, at enhver smartphone, du kan købe i dag, har en form for AES-acceleration og kører hurtigere og med lavere strømforbrug med denne kryptering end med ChaCha20.
Det er klart, at næsten alle desktop/server-processorer købt i de sidste par år har AES-NI.
Derfor forventer jeg, at AES klarer sig bedre end ChaCha20 i hvert enkelt scenarie. WireGuards officielle dokumentation nævner, at med AVX512 vil ChaCha20-Poly1305 overgå AES-NI, men denne instruktionssætudvidelse vil kun være tilgængelig på større CPU'er, hvilket igen ikke hjælper med mindre og mere mobil hardware, som altid vil være hurtigere med AES - N.I.
Jeg er ikke sikker på, om dette kunne have været forudset under udviklingen af WireGuard, men i dag er det faktum, at det er naglet til kryptering alene, allerede en ulempe, som måske ikke påvirker dets drift særlig godt.
IPsec giver dig mulighed for frit at vælge, hvilken kryptering der passer bedst til dit tilfælde. Og det er selvfølgelig nødvendigt, hvis du for eksempel vil overføre 10 eller flere gigabyte data gennem en VPN-forbindelse.
Integrationsproblemer i Linux
Selvom WireGuard har valgt en moderne krypteringsprotokol, giver dette allerede mange problemer. Og så i stedet for at bruge det, der understøttes af kernen ud af boksen, er integrationen af WireGuard blevet forsinket i årevis på grund af manglen på disse primitiver i Linux.
Jeg er ikke helt sikker på, hvordan situationen er på andre styresystemer, men det er nok ikke meget anderledes end på Linux.
Hvordan ser virkeligheden ud?
Hver gang en klient beder mig om at oprette en VPN-forbindelse til dem, støder jeg desværre på det problem, at de bruger forældede legitimationsoplysninger og kryptering. 3DES i forbindelse med MD5 er stadig almindelig praksis, ligesom AES-256 og SHA1. Og selvom sidstnævnte er lidt bedre, er det ikke noget, der skal bruges i 2020.
Til nøgleudveksling altid RSA bruges - et langsomt, men ret sikkert værktøj.
Mine kunder er tilknyttet toldmyndigheder og andre statslige organisationer og institutioner, samt til store virksomheder, hvis navne er kendt over hele verden. De bruger alle en anmodningsformular, der blev oprettet for årtier siden, og muligheden for at bruge SHA-512 blev simpelthen aldrig tilføjet. Jeg kan ikke sige, at det på en eller anden måde tydeligt påvirker teknologiske fremskridt, men åbenbart bremser det virksomhedsprocessen.
Det gør mig ondt at se dette, fordi IPsec har understøttet elliptiske kurver direkte siden år 2005. Curve25519 er også nyere og tilgængelig til brug. Der er også alternativer til AES som Camellia og ChaCha20, men det er åbenbart ikke alle, der understøttes af større leverandører som Cisco og andre.
Og folk udnytter det. Der er mange Cisco-sæt, der er mange sæt designet til at fungere med Cisco. De er markedsledere i dette segment og er ikke særlig interesserede i nogen form for innovation.
Ja, situationen [i virksomhedssegmentet] er forfærdelig, men vi vil ikke se nogen ændringer på grund af WireGuard. Leverandører vil sandsynligvis aldrig se nogen problemer med ydeevnen med det værktøj og kryptering, de allerede bruger, vil ikke se nogen problemer med IKEv2, og de leder derfor ikke efter alternativer.
Generelt, har du nogensinde tænkt på at opgive Cisco?
Benchmarks
Og lad os nu gå videre til benchmarks fra WireGuard-dokumentationen. Selvom denne [dokumentation] ikke er en videnskabelig artikel, forventede jeg stadig, at udviklerne ville tage en mere videnskabelig tilgang eller bruge en videnskabelig tilgang som reference. Eventuelle benchmarks er ubrugelige, hvis de ikke kan reproduceres, og endnu mere ubrugelige, når de anskaffes i laboratoriet.
I Linux-bygningen af WireGuard udnytter den brugen af GSO - Generic Segmentation Offloading. Takket være ham opretter klienten en enorm pakke på 64 kilobyte og krypterer / dekrypterer den på én gang. Således reduceres omkostningerne ved at påkalde og implementere kryptografiske operationer. Hvis du ønsker at maksimere gennemløbet af din VPN-forbindelse, er dette en god idé.
Men som sædvanligt er virkeligheden ikke så enkel. At sende en så stor pakke til en netværksadapter kræver, at den skæres i mange mindre pakker. Den normale sendestørrelse er 1500 bytes. Det vil sige, at vores kæmpe på 64 kilobytes vil blive opdelt i 45 pakker (1240 bytes information og 20 bytes af IP-headeren). Så vil de i et stykke tid fuldstændig blokere netværksadapterens arbejde, fordi de skal sendes sammen og på én gang. Som et resultat vil dette føre til et prioritetsspring, og pakker som VoIP, for eksempel, vil blive sat i kø.
Således opnås den høje gennemstrømning, som WireGuard så dristigt hævder, på bekostning af at bremse netværket af andre applikationer. Og WireGuard-holdet er allerede dette er min konklusion.
Men lad os komme videre.
Ifølge benchmarks i den tekniske dokumentation viser forbindelsen en gennemstrømning på 1011 Mbps.
Imponerende.
Dette er især imponerende på grund af det faktum, at den maksimale teoretiske gennemstrømning af en enkelt Gigabit Ethernet-forbindelse er 966 Mbps med en pakkestørrelse på 1500 bytes minus 20 bytes til IP-headeren, 8 bytes til UDP-headeren og 16 bytes til headeren af selve WireGuard . Der er endnu en IP-header i den indkapslede pakke og en anden i TCP til 20 bytes. Så hvor kom denne ekstra båndbredde fra?
Med enorme rammer og fordelene ved GSO, vi talte om ovenfor, ville det teoretiske maksimum for en rammestørrelse på 9000 bytes være 1014 Mbps. Normalt er en sådan gennemstrømning uopnåelig i virkeligheden, fordi den er forbundet med store vanskeligheder. Jeg kan således kun gå ud fra, at testen er udført med endnu federe overdimensionerede frames på 64 kilobyte med et teoretisk maksimum på 1023 Mbps, hvilket kun understøttes af nogle netværksadaptere. Men dette er absolut uanvendeligt under virkelige forhold, eller kan kun bruges mellem to direkte forbundne stationer, udelukkende inden for testbænken.
Men da VPN-tunnelen videresendes mellem to værter ved hjælp af en internetforbindelse, der slet ikke understøtter jumborammer, kan det opnåede resultat på bænken ikke tages som et benchmark. Dette er simpelthen en urealistisk laboratoriepræstation, der er umulig og uanvendelig under virkelige kampforhold.
Selv når jeg sad i datacentret, kunne jeg ikke overføre billeder større end 9000 bytes.
Kriteriet for anvendelighed i det virkelige liv er absolut overtrådt, og som jeg tror, miskrediterede forfatteren af den udførte "måling" sig selv alvorligt af indlysende årsager.
Sidste glimt af håb
WireGuard-hjemmesiden taler meget om containere, og det bliver tydeligt, hvad det egentlig er beregnet til.
En enkel og hurtig VPN, der ikke kræver nogen konfiguration og kan implementeres og konfigureres med massive orkestreringsværktøjer, som Amazon har i deres sky. Specifikt bruger Amazon de nyeste hardwarefunktioner, som jeg nævnte tidligere, såsom AVX512. Dette gøres for at fremskynde arbejdet og ikke være bundet til x86 eller nogen anden arkitektur.
De optimerer gennemløb og pakker større end 9000 bytes - disse vil være enorme indkapslede rammer, så containere kan kommunikere med hinanden, eller til sikkerhedskopiering, oprettelse af snapshots eller implementering af de samme containere. Selv dynamiske IP-adresser vil ikke påvirke driften af WireGuard på nogen måde i tilfælde af det scenarie, jeg beskrev.
Godt spillet. Strålende implementering og meget tynd, næsten referenceprotokol.
Men det passer bare ikke ind i en verden uden for et datacenter, som du helt kontrollerer. Hvis du tager risikoen og begynder at bruge WireGuard, bliver du nødt til konstant at gå på kompromis med designet og implementeringen af krypteringsprotokollen.
Output
Det er nemt for mig at konkludere, at WireGuard ikke er klar endnu.
Det var tænkt som en let og hurtig løsning på en række problemer med eksisterende løsninger. Desværre, af hensyn til disse løsninger, ofrede han mange funktioner, der vil være relevante for de fleste brugere. Derfor kan den ikke erstatte IPsec eller OpenVPN.
For at WireGuard kan blive konkurrencedygtig, skal den tilføje mindst en IP-adresseindstilling og en routing og DNS-konfiguration. Det er klart, hvad krypterede kanaler er til.
Sikkerhed er min topprioritet, og lige nu har jeg ingen grund til at tro, at IKE eller TLS på en eller anden måde er kompromitteret eller ødelagt. Moderne kryptering er understøttet i dem begge, og de er blevet bevist af årtiers drift. Bare fordi noget er nyere, betyder det ikke, at det er bedre.
Interoperabilitet er ekstremt vigtigt, når du kommunikerer med tredjeparter, hvis stationer du ikke kontrollerer. IPsec er de facto-standarden og understøttes næsten overalt. Og han arbejder. Og uanset hvordan det ser ud, er WireGuard i teorien muligvis ikke kompatibel, selv med forskellige versioner af sig selv.
Enhver kryptografisk beskyttelse brydes før eller siden og skal derfor udskiftes eller opdateres.
At benægte alle disse fakta og blindt ville bruge WireGuard til at forbinde din iPhone til din hjemmearbejdsstation er bare en mesterklasse i at stikke hovedet i sandet.
Kilde: www.habr.com