WireGuard har fått mye oppmerksomhet i det siste, faktisk er det den nye stjernen blant VPN-er. Men er han så god som han ser ut til? Jeg vil gjerne diskutere noen observasjoner og gjennomgå implementeringen av WireGuard for å forklare hvorfor det ikke er en løsning å erstatte IPsec eller OpenVPN.
I denne artikkelen vil jeg avlive noen av mytene [rundt WireGuard]. Ja, det vil ta lang tid å lese, så hvis du ikke har laget deg en kopp te eller kaffe, så er det på tide å gjøre det. Jeg vil også si takk til Peter for å rette opp mine kaotiske tanker.
Jeg setter meg ikke som mål å diskreditere utviklerne av WireGuard, devaluere deres innsats eller ideer. Produktet deres fungerer, men personlig tror jeg at det presenteres helt annerledes enn det det egentlig er – det presenteres som en erstatning for IPsec og OpenVPN, som faktisk rett og slett ikke eksisterer nå.
Som en merknad vil jeg legge til at ansvaret for en slik posisjonering av WireGuard ligger hos media som snakket om det, og ikke prosjektet selv eller dets skapere.
Det har ikke vært mye gode nyheter om Linux-kjernen i det siste. Så vi ble fortalt om de monstrøse sårbarhetene til prosessoren, som ble utjevnet av programvare, og Linus Torvalds snakket om det for frekt og kjedelig, på det utilitaristiske språket til utvikleren. En planlegger eller en null-nivå nettverksstabel er heller ikke veldig klare emner for glansede magasiner. Og her kommer WireGuard.
På papiret høres alt flott ut: en spennende ny teknologi.
Men la oss se litt nærmere på det.
WireGuard hvitt papir
Denne artikkelen er basert på skrevet av Jason Donenfeld. Der forklarer han konseptet, formålet og den tekniske implementeringen av [WireGuard] i Linux-kjernen.
Den første setningen lyder:
WireGuard […] tar sikte på å erstatte både IPsec i de fleste brukstilfeller og andre populære brukerrom og/eller TLS-baserte løsninger som OpenVPN, samtidig som de er sikrere, mer effektive og enklere å bruke [verktøy].
Selvfølgelig er den største fordelen med alle nye teknologier deres lette [sammenlignet med forgjengere]. Men en VPN bør også være det effektivt og trygt.
Så, hva er neste?
Hvis du sier at dette ikke er det du trenger [fra en VPN], så kan du avslutte lesingen her. Jeg vil imidlertid merke meg at slike oppgaver er satt for enhver annen tunnelteknologi.
Det mest interessante av sitatet ovenfor ligger i ordene "i de fleste tilfeller", som selvfølgelig ble ignorert av pressen. Og så er vi der vi endte opp på grunn av kaoset skapt av denne uaktsomheten - i denne artikkelen.
Vil WireGuard erstatte min [IPsec] site-to-site VPN?
Nei. Det er rett og slett ingen sjanse for at store leverandører som Cisco, Juniper og andre vil kjøpe WireGuard for produktene deres. De "hopper ikke på passerende tog" på farten med mindre det er et stort behov for å gjøre det. Senere skal jeg gå over noen av årsakene til at de sannsynligvis ikke vil kunne få WireGuard-produktene sine om bord selv om de skulle ønske det.
Vil WireGuard ta min RoadWarrior fra den bærbare datamaskinen til datasenteret?
Nei. Akkurat nå har ikke WireGuard et stort antall viktige funksjoner implementert for at den skal kunne gjøre noe slikt. For eksempel kan den ikke bruke dynamiske IP-adresser på tunnelserversiden, og dette alene bryter hele scenariet med slik bruk av produktet.
IPFire brukes ofte til billige Internett-koblinger, for eksempel DSL- eller kabeltilkoblinger. Dette er fornuftig for små eller mellomstore bedrifter som ikke trenger rask fiber. [Notat fra oversetteren: ikke glem at når det gjelder kommunikasjon, er Russland og noen CIS-land langt foran Europa og USA, fordi vi begynte å bygge nettverkene våre mye senere og med bruken av Ethernet og fiberoptiske nettverk som et standard var det lettere for oss å bygge opp igjen. I de samme landene i EU eller USA er xDSL bredbåndsaksess med en hastighet på 3-5 Mbps fortsatt den generelle normen, og en fiberoptisk tilkobling koster noen urealistiske penger etter våre standarder. Derfor snakker forfatteren av artikkelen om DSL eller kabelforbindelse som normen, og ikke eldgamle tider.] DSL, kabel, LTE (og andre trådløse tilgangsmetoder) har imidlertid dynamiske IP-adresser. Selvfølgelig, noen ganger endrer de seg ikke ofte, men de endrer seg.
Det er et delprosjekt som heter , som legger til en brukerplassdemon for å overvinne denne mangelen. Et stort problem med brukerscenariet beskrevet ovenfor er forverringen av dynamisk IPv6-adressering.
Fra distributørens synspunkt ser ikke alt dette veldig bra ut heller. Et av designmålene var å holde protokollen enkel og ren.
Dessverre har faktisk alt dette blitt for enkelt og primitivt, slik at vi må bruke tilleggsprogramvare for at hele dette designet skal være levedyktig i reell bruk.
Er WireGuard så enkel å bruke?
Ikke ennå. Jeg sier ikke at WireGuard aldri vil være et godt alternativ for tunnelering mellom to punkter, men foreløpig er det bare en alfaversjon av produktet det skal være.
Men hva gjør han egentlig? Er IPsec virkelig så mye vanskeligere å vedlikeholde?
Åpenbart ikke. IPsec-leverandøren har tenkt på dette og sender produktet deres sammen med et grensesnitt, for eksempel med IPFire.
For å sette opp en VPN-tunnel over IPsec, trenger du fem sett med data som du trenger for å legge inn i konfigurasjonen: din egen offentlige IP-adresse, den offentlige IP-adressen til mottakeren, subnettene du vil gjøre offentlig gjennom denne VPN-tilkoblingen og forhåndsdelte nøkkelen. Dermed blir VPN satt opp i løpet av minutter og er kompatibel med enhver leverandør.
Dessverre er det noen få unntak fra denne historien. Alle som har prøvd å tunnelere over IPsec til en OpenBSD-maskin vet hva jeg snakker om. Det er et par flere smertefulle eksempler, men faktisk er det mange, mange flere gode fremgangsmåter for bruk av IPsec.
Om protokollkompleksitet
Sluttbrukeren trenger ikke å bekymre seg for kompleksiteten til protokollen.
Hvis vi levde i en verden hvor dette var en reell bekymring for brukeren, så ville vi for lengst ha kvittet oss med SIP, H.323, FTP og andre protokoller laget for mer enn ti år siden som ikke fungerer godt med NAT.
Det er grunner til at IPsec er mer kompleks enn WireGuard: den gjør mye flere ting. For eksempel brukerautentisering med pålogging/passord eller SIM-kort med EAP. Den har en utvidet mulighet til å legge til nye .
Og det har ikke WireGuard.
Og dette betyr at WireGuard vil gå i stykker på et tidspunkt, fordi en av de kryptografiske primitivene vil svekkes eller bli fullstendig kompromittert. Forfatteren av den tekniske dokumentasjonen sier dette:
Det er verdt å merke seg at WireGuard er kryptografisk oppfattet. Den mangler bevisst fleksibiliteten til chiffer og protokoller. Hvis det blir funnet alvorlige hull i underliggende primitiver, må alle endepunkter oppdateres. Som du kan se fra den pågående strømmen av SLL/TLS-sårbarheter, har fleksibiliteten til kryptering nå økt enormt.
Den siste setningen er helt riktig.
Å oppnå konsensus om hvilken kryptering som skal brukes gjør protokoller som IKE og TLS mer kompleks. For komplisert? Ja, sårbarheter er ganske vanlige i TLS/SSL, og det er ikke noe alternativ til dem.
På å ignorere reelle problemer
Tenk deg at du har en VPN-server med 200 kampklienter et sted rundt om i verden. Dette er en ganske standard brukssak. Hvis du må endre krypteringen, må du levere oppdateringen til alle kopier av WireGuard på disse bærbare datamaskinene, smarttelefonene og så videre. Samtidig levere. Det er bokstavelig talt umulig. Administratorer som prøver å gjøre dette vil ta måneder å distribuere de nødvendige konfigurasjonene, og det vil bokstavelig talt ta et middels stort selskap år å gjennomføre en slik hendelse.
IPsec og OpenVPN tilbyr en chifferforhandlingsfunksjon. Derfor vil den gamle også fungere i en tid, hvoretter du slår på den nye krypteringen. Dette vil tillate nåværende kunder å oppgradere til den nye versjonen. Etter at oppdateringen er rullet ut, slår du ganske enkelt av den sårbare krypteringen. Og det er det! Klar! du er vakker! Klienter vil ikke engang merke det.
Dette er faktisk et veldig vanlig tilfelle for store distribusjoner, og til og med OpenVPN har noen problemer med dette. Bakoverkompatibilitet er viktig, og selv om du bruker svakere kryptering, er dette for mange ikke en grunn til å legge ned en virksomhet. Fordi det vil lamme arbeidet til hundrevis av kunder på grunn av manglende evne til å gjøre jobben sin.
WireGuard-teamet har gjort protokollen deres enklere, men helt ubrukelig for folk som ikke har konstant kontroll over begge jevnaldrende i tunnelen deres. Etter min erfaring er dette det vanligste scenariet.
Kryptografi!
Men hva er denne interessante nye krypteringen som WireGuard bruker?
WireGuard bruker Curve25519 for nøkkelutveksling, ChaCha20 for kryptering og Poly1305 for dataautentisering. Det fungerer også med SipHash for hash-nøkler og BLAKE2 for hash.
ChaCha20-Poly1305 er standardisert for IPsec og OpenVPN (over TLS).
Det er åpenbart at utviklingen av Daniel Bernstein brukes veldig ofte. BLAKE2 er etterfølgeren til BLAKE, en SHA-3-finalist som ikke vant på grunn av sin likhet med SHA-2. Hvis SHA-2 skulle bli ødelagt, var det en god sjanse for at BLAKE også ville bli kompromittert.
IPsec og OpenVPN trenger ikke SipHash på grunn av deres design. Så det eneste som for øyeblikket ikke kan brukes med dem er BLAKE2, og det er bare til det er 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 forbindelse med MD5.
Så jeg kom til den konklusjonen at nesten det samme settet med kryptografiske verktøy brukes i alle VPN-er. Derfor er WireGuard verken mer eller mindre sikker enn noe annet nåværende produkt når det kommer til kryptering eller integriteten til overførte data.
Men selv dette er ikke det viktigste, som er verdt å ta hensyn til i henhold til den offisielle dokumentasjonen av prosjektet. Det viktigste er tross alt hastighet.
Er WireGuard raskere enn andre VPN-løsninger?
Kort sagt: nei, ikke raskere.
ChaCha20 er et strømchiffer som er enklere å implementere i programvare. Den krypterer en bit om gangen. Blokkprotokoller som AES krypterer en blokk med 128 biter om gangen. Mye flere transistorer kreves for å implementere maskinvarestøtte, så større prosessorer kommer med AES-NI, en instruksjonssettutvidelse som utfører noen av oppgavene i krypteringsprosessen for å øke hastigheten.
Det var forventet at AES-NI aldri ville komme inn i smarttelefoner [men det gjorde det - ca. per.]. For dette ble ChaCha20 utviklet som et lett, batterisparende alternativ. Derfor kan det komme som en nyhet for deg at hver smarttelefon du kan kjøpe i dag har en slags AES-akselerasjon og kjører raskere og med lavere strømforbruk med denne krypteringen enn med ChaCha20.
Tydeligvis har omtrent alle stasjonære/server-prosessorer kjøpt i løpet av de siste par årene AES-NI.
Derfor forventer jeg at AES vil overgå ChaCha20 i hvert eneste scenario. WireGuards offisielle dokumentasjon nevner at med AVX512 vil ChaCha20-Poly1305 overgå AES-NI, men denne instruksjonssettutvidelsen vil kun være tilgjengelig på større CPUer, noe som igjen ikke vil hjelpe med mindre og mer mobil maskinvare, som alltid vil være raskere med AES - N.I.
Jeg er ikke sikker på om dette kunne vært forutsett under utviklingen av WireGuard, men i dag er det faktum at det er spikret til kryptering alene allerede en ulempe som kanskje ikke påvirker driften særlig godt.
IPsec lar deg fritt velge hvilken kryptering som passer best for ditt tilfelle. Og selvfølgelig er dette nødvendig hvis du for eksempel ønsker å overføre 10 eller flere gigabyte med data gjennom en VPN-tilkobling.
Integrasjonsproblemer i Linux
Selv om WireGuard har valgt en moderne krypteringsprotokoll, skaper dette allerede mange problemer. Og så, i stedet for å bruke det som støttes av kjernen ut av esken, har integreringen av WireGuard blitt forsinket i årevis på grunn av mangelen på disse primitivene i Linux.
Jeg er ikke helt sikker på hvordan situasjonen er på andre operativsystemer, men det er nok ikke mye annerledes enn på Linux.
Hvordan ser virkeligheten ut?
Dessverre, hver gang en klient ber meg om å sette opp en VPN-tilkobling for dem, får jeg problemet at de bruker utdatert legitimasjon og kryptering. 3DES i forbindelse med MD5 er fortsatt vanlig praksis, det samme er AES-256 og SHA1. Og selv om sistnevnte er litt bedre, er ikke dette noe som bør brukes i 2020.
For nøkkelbytte alltid RSA brukes - et tregt, men ganske sikkert verktøy.
Mine klienter er knyttet til tollmyndigheter og andre statlige organisasjoner og institusjoner, samt med store selskaper hvis navn er kjent over hele verden. De bruker alle et forespørselsskjema som ble opprettet for flere tiår siden, og muligheten til å bruke SHA-512 ble rett og slett aldri lagt til. Jeg kan ikke si at det på en eller annen måte tydelig påvirker teknologisk fremgang, men åpenbart bremser det bedriftsprosessen.
Det gjør meg vondt å se dette fordi IPsec har støttet elliptiske kurver direkte siden 2005. Curve25519 er også nyere og tilgjengelig for bruk. Det finnes også alternativer til AES som Camellia og ChaCha20, men åpenbart ikke alle støttes av store leverandører som Cisco og andre.
Og folk utnytter det. Det er mange Cisco-sett, det er mange sett designet for å fungere med Cisco. De er markedsledere i dette segmentet og er lite interessert i noen form for innovasjon.
Ja, situasjonen [i bedriftssegmentet] er forferdelig, men vi vil ikke se noen endringer på grunn av WireGuard. Leverandører vil sannsynligvis aldri se noen ytelsesproblemer med verktøyet og krypteringen de allerede bruker, vil ikke se noen problemer med IKEv2, og derfor leter de ikke etter alternativer.
Generelt, har du noen gang tenkt på å forlate Cisco?
Benchmarks
Og la oss nå gå videre til benchmarkene fra WireGuard-dokumentasjonen. Selv om denne [dokumentasjonen] ikke er en vitenskapelig artikkel, forventet jeg likevel at utviklerne skulle ta en mer vitenskapelig tilnærming, eller bruke en vitenskapelig tilnærming som referanse. Eventuelle benchmarks er ubrukelige hvis de ikke kan reproduseres, og enda mer ubrukelige når de er anskaffet i laboratoriet.
I Linux-bygget til WireGuard drar den fordel av å bruke GSO - Generic Segmentation Offloading. Takket være ham lager klienten en enorm pakke på 64 kilobyte og krypterer / dekrypterer den på én gang. Dermed reduseres kostnadene ved å påkalle og implementere kryptografiske operasjoner. Hvis du vil maksimere gjennomstrømningen til VPN-tilkoblingen din, er dette en god idé.
Men som vanlig er virkeligheten ikke så enkel. Å sende en så stor pakke til et nettverkskort krever at den kuttes i mange mindre pakker. Normal sendestørrelse er 1500 byte. Det vil si at vår gigant på 64 kilobyte vil bli delt inn i 45 pakker (1240 byte med informasjon og 20 byte av IP-headeren). Deretter vil de for en stund blokkere arbeidet til nettverksadapteren fullstendig, fordi de må sendes sammen og på en gang. Som et resultat vil dette føre til et prioritert hopp, og pakker som for eksempel VoIP vil stå i kø.
Dermed oppnås den høye gjennomstrømningen som WireGuard så dristig hevder, på bekostning av å bremse nettverksbyggingen til andre applikasjoner. Og WireGuard-teamet er allerede dette er min konklusjon.
Men la oss gå videre.
I følge referansene i den tekniske dokumentasjonen viser forbindelsen en gjennomstrømning på 1011 Mbps.
Imponerende.
Dette er spesielt imponerende på grunn av det faktum at den maksimale teoretiske gjennomstrømningen for en enkelt Gigabit Ethernet-tilkobling er 966 Mbps med en pakkestørrelse på 1500 byte minus 20 byte for IP-headeren, 8 byte for UDP-headeren og 16 byte for headeren til selve WireGuard . Det er en IP-header til i den innkapslede pakken og en annen i TCP for 20 byte. Så hvor kom denne ekstra båndbredden fra?
Med enorme rammer og fordelene med GSO vi snakket om ovenfor, ville det teoretiske maksimum for en rammestørrelse på 9000 byte være 1014 Mbps. Vanligvis er slik gjennomstrømning uoppnåelig i virkeligheten, fordi det er forbundet med store vanskeligheter. Dermed kan jeg bare anta at testen ble utført med enda fetere overdimensjonerte rammer på 64 kilobyte med et teoretisk maksimum på 1023 Mbps, som kun støttes av enkelte nettverkskort. Men dette er absolutt ubrukelig under reelle forhold, eller kan bare brukes mellom to direkte tilkoblede stasjoner, utelukkende innenfor testbenken.
Men siden VPN-tunnelen videresendes mellom to verter ved hjelp av en Internett-tilkobling som ikke støtter jumborammer i det hele tatt, kan ikke resultatet som er oppnådd på benken tas som en målestokk. Dette er rett og slett en urealistisk laboratorieprestasjon som er umulig og ubrukelig under virkelige kampforhold.
Selv når jeg satt i datasenteret, kunne jeg ikke overføre rammer større enn 9000 byte.
Kriteriet for anvendelighet i det virkelige liv er absolutt brutt, og som jeg tror, har forfatteren av "målingen" som ble utført, alvorlig diskreditert seg selv av åpenbare grunner.
Siste glimt av håp
Nettstedet WireGuard snakker mye om containere og det blir tydelig hva det egentlig er ment for.
En enkel og rask VPN som ikke krever noen konfigurasjon og som kan distribueres og konfigureres med massive orkestreringsverktøy som Amazon har i skyen deres. Spesielt bruker Amazon de nyeste maskinvarefunksjonene som jeg nevnte tidligere, for eksempel AVX512. Dette gjøres for å fremskynde arbeidet og ikke være knyttet til x86 eller noen annen arkitektur.
De optimerer gjennomstrømning og pakker større enn 9000 byte – dette vil være enorme innkapslede rammer for containere for å kommunisere med hverandre, eller for sikkerhetskopiering, lage øyeblikksbilder eller distribuere de samme containerne. Selv dynamiske IP-adresser vil ikke påvirke driften av WireGuard på noen måte i tilfellet med scenariet jeg beskrev.
Bra spilt. Strålende implementering og veldig tynn, nesten referanseprotokoll.
Men det passer bare ikke inn i en verden utenfor et datasenter som du kontrollerer fullstendig. Hvis du tar risikoen og begynner å bruke WireGuard, må du inngå konstante kompromisser i utformingen og implementeringen av krypteringsprotokollen.
Utgang
Det er lett for meg å konkludere med at WireGuard ikke er klar ennå.
Det ble tenkt som en lett og rask løsning på en rekke problemer med eksisterende løsninger. Dessverre, av hensyn til disse løsningene, ofret han mange funksjoner som vil være relevante for de fleste brukere. Det er derfor den ikke kan erstatte IPsec eller OpenVPN.
For at WireGuard skal bli konkurransedyktig, må den legge til minst en IP-adresseinnstilling og en ruting og DNS-konfigurasjon. Det er åpenbart dette krypterte kanaler er for.
Sikkerhet er min toppprioritet, og akkurat nå har jeg ingen grunn til å tro at IKE eller TLS på en eller annen måte er kompromittert eller ødelagt. Moderne kryptering støttes i begge, og de har blitt bevist av flere tiår med drift. Bare fordi noe er nyere betyr ikke det at det er bedre.
Interoperabilitet er ekstremt viktig når du kommuniserer med tredjeparter hvis stasjoner du ikke kontrollerer. IPsec er de facto-standarden og støttes nesten overalt. Og han jobber. Og uansett hvordan det ser ut, i teorien vil WireGuard i fremtiden kanskje ikke være kompatibel selv med forskjellige versjoner av seg selv.
Enhver kryptografisk beskyttelse brytes før eller siden og må følgelig erstattes eller oppdateres.
Å benekte alle disse fakta og blindt ønske å bruke WireGuard til å koble iPhone til hjemmearbeidsstasjonen er bare en mesterklasse i å stikke hodet i sanden.
Kilde: www.habr.com