WireGuard si v poslední době získává velkou pozornost, ve skutečnosti je to nová hvězda mezi VPN. Ale je tak dobrý, jak se zdá? Rád bych probral některá pozorování a zhodnotil implementaci WireGuard, abych vysvětlil, proč není řešením nahradit IPsec nebo OpenVPN.
V tomto článku bych rád vyvrátil některé mýty [kolem WireGuard]. Ano, čtení bude trvat dlouho, takže pokud jste si neudělali šálek čaje nebo kávy, je čas to udělat. Také bych rád poděkoval Petrovi za napravení mých chaotických myšlenek.
Nedávám si za cíl zdiskreditovat vývojáře WireGuard, znehodnotit jejich úsilí nebo nápady. Jejich produkt funguje, ale osobně si myslím, že je prezentován úplně jinak, než ve skutečnosti je - je prezentován jako náhrada za IPsec a OpenVPN, které ve skutečnosti nyní prostě neexistují.
Jako poznámku dodávám, že odpovědnost za takové umístění WireGuardu nesou média, která o něm mluvila, nikoli samotný projekt nebo jeho tvůrci.
V poslední době není o linuxovém jádře mnoho dobrých zpráv. Bylo nám tedy řečeno o monstrózních zranitelnostech procesoru, které byly vyrovnány softwarem, a Linus Torvalds o tom mluvil příliš hrubě a nudně, utilitárním jazykem vývojáře. Plánovač nebo síťový zásobník nulové úrovně také nejsou příliš jasná témata pro lesklé časopisy. A tady přichází WireGuard.
Na papíře to všechno zní skvěle: vzrušující nová technologie.
Ale pojďme se na to podívat trochu blíže.
Bílý papír WireGuard
Tento článek je založen na napsal Jason Donenfeld. Tam vysvětluje koncept, účel a technickou implementaci [WireGuard] v linuxovém jádře.
První věta zní:
WireGuard […] si klade za cíl nahradit jak IPsec ve většině případů použití, tak další populární řešení založená na uživatelském prostoru a/nebo TLS, jako je OpenVPN, přičemž je bezpečnější, výkonnější a snadněji použitelný [nástroj].
Hlavní výhodou všech nových technologií je samozřejmě jejich jednoduchost [ve srovnání s předchůdci]. Ale VPN by také měla být efektivní a bezpečné.
Takže, co bude dál?
Pokud říkáte, že to není to, co potřebujete [z VPN], můžete čtení ukončit zde. Upozorňuji však, že takové úkoly jsou stanoveny pro jakoukoli jinou technologii tunelování.
Nejzajímavější z výše uvedeného citátu tkví ve slovech „ve většině případů“, která byla samozřejmě tiskem ignorována. A tak jsme tam, kde jsme kvůli chaosu vytvořenému touto nedbalostí skončili – v tomto článku.
Nahradí WireGuard mou VPN typu site-to-site [IPsec]?
Ne. Prostě není šance, že by si velcí prodejci jako Cisco, Juniper a další pořídili WireGuard pro své produkty. "Nenaskakují do projíždějících vlaků" v pohybu, pokud to není potřeba. Později se podívám na některé z důvodů, proč pravděpodobně nebudou moci dostat své produkty WireGuard na palubu, i když by chtěli.
Přenese WireGuard můj RoadWarrior z mého notebooku do datového centra?
Ne. Právě teď nemá WireGuard implementováno velké množství důležitých funkcí, aby něco takového dokázal. Nemůže například používat dynamické IP adresy na straně tunelového serveru, a to samo o sobě narušuje celý scénář takového použití produktu.
IPFire se často používá pro levné internetové připojení, jako je DSL nebo kabelové připojení. To dává smysl pro malé nebo střední podniky, které nepotřebují rychlé vlákno. [Poznámka od překladatele: nezapomeňte, že co se týče komunikace, Rusko a některé země SNS jsou daleko před Evropou a Spojenými státy, protože naše sítě jsme začali budovat mnohem později a s příchodem ethernetových a optických sítí jako standard, bylo pro nás snazší přestavět. Ve stejných zemích EU nebo USA je širokopásmový přístup xDSL rychlostí 3-5 Mbps stále běžnou normou a optické připojení stojí na naše poměry nereálné peníze. Proto autor článku mluví o DSL nebo kabelovém připojení jako o normě, a ne o dávných dobách.] DSL, kabel, LTE (a další bezdrátové přístupové metody) však mají dynamické IP adresy. Samozřejmě se někdy nemění často, ale mění se.
Existuje podprojekt tzv , který přidává démona uživatelského prostoru k překonání tohoto nedostatku. Obrovským problémem výše popsaného uživatelského scénáře je zhoršení dynamického adresování IPv6.
Z pohledu distributora to vše také nevypadá moc dobře. Jedním z cílů návrhu bylo udržet protokol jednoduchý a čistý.
Bohužel se to všechno ve skutečnosti stalo příliš jednoduchým a primitivním, takže musíme použít další software, aby byl celý tento návrh životaschopný v reálném použití.
Je WireGuard tak snadné?
Ještě ne. Neříkám, že WireGuard nikdy nebude dobrou alternativou pro tunelování mezi dvěma body, ale zatím je to jen alfa verze produktu, kterým by měl být.
Ale co potom vlastně dělá? Je IPsec opravdu o tolik těžší udržovat?
Očividně ne. Dodavatel IPsec na to myslel a dodává svůj produkt spolu s rozhraním, jako je IPFire.
K nastavení VPN tunelu přes IPsec budete potřebovat pět sad dat, které budete muset zadat do konfigurace: svou vlastní veřejnou IP adresu, veřejnou IP adresu přijímající strany, podsítě, které chcete zveřejnit. toto připojení VPN a předsdílený klíč. VPN je tedy nastavena během několika minut a je kompatibilní s jakýmkoli dodavatelem.
Bohužel v tomto příběhu existuje několik výjimek. Kdo zkoušel tunelovat přes IPsec na OpenBSD stroj, ví, o čem mluvím. Existuje několik bolestivějších příkladů, ale ve skutečnosti existuje mnohem, mnohem více osvědčených postupů pro používání IPsec.
O složitosti protokolu
Koncový uživatel se nemusí obávat složitosti protokolu.
Kdybychom žili ve světě, kde by to byla skutečná starost uživatele, pak bychom se už dávno zbavili SIP, H.323, FTP a dalších protokolů vytvořených před více než deseti lety, které s NATem nefungují dobře.
Existují důvody, proč je protokol IPsec složitější než WireGuard: umí mnohem více věcí. Například autentizace uživatele pomocí přihlašovacího jména / hesla nebo SIM karty s EAP. Má rozšířenou schopnost přidávat nové .
A to WireGuard nemá.
A to znamená, že WireGuard se v určitém okamžiku zlomí, protože jedno z kryptografických primitiv oslabí nebo bude zcela kompromitováno. Autor technické dokumentace říká toto:
Stojí za zmínku, že WireGuard je kryptograficky přesvědčený. Záměrně postrádá flexibilitu šifer a protokolů. Pokud se v základních primitivech najdou vážné díry, bude nutné aktualizovat všechny koncové body. Jak můžete vidět z probíhajícího proudu zranitelností SLL/TLS, flexibilita šifrování se nyní nesmírně zvýšila.
Poslední věta je naprosto správná.
Dosažení konsenzu o tom, jaké šifrování použít, vytváří protokoly jako IKE a TLS více komplex. Příliš komplikované? Ano, zranitelnosti jsou v TLS/SSL poměrně běžné a neexistuje k nim žádná alternativa.
Na ignorování skutečných problémů
Představte si, že máte někde po světě VPN server s 200 bojovými klienty. Toto je docela standardní případ použití. Pokud musíte změnit šifrování, musíte aktualizaci doručit do všech kopií WireGuard na těchto noteboocích, chytrých telefonech a tak dále. Zároveň dodat. Je to doslova nemožné. Správcům, kteří se o to pokoušejí, zabere nasazení požadovaných konfigurací měsíce a středně velké společnosti bude trvat doslova roky, než takovou událost spustí.
IPsec a OpenVPN nabízejí funkci vyjednávání šifry. Proto po nějakou dobu, po které zapnete nové šifrování, bude fungovat i to staré. To umožní stávajícím zákazníkům upgradovat na novou verzi. Po zavedení aktualizace jednoduše vypnete zranitelné šifrování. A to je vše! Připraveno! jsi nádherná! Klienti si toho ani nevšimnou.
Toto je ve skutečnosti velmi běžný případ pro velká nasazení a dokonce i OpenVPN s tím má určité potíže. Zpětná kompatibilita je důležitá a i když používáte slabší šifrování, pro mnohé to není důvod k uzavření firmy. Protože to ochromí práci stovek zákazníků kvůli neschopnosti vykonávat svou práci.
Tým WireGuard udělal jejich protokol jednodušší, ale zcela nepoužitelný pro lidi, kteří nemají neustálou kontrolu nad oběma vrstevníky ve svém tunelu. Podle mých zkušeností je to nejběžnější scénář.
Kryptografie!
Ale co je to zajímavé nové šifrování, které WireGuard používá?
WireGuard používá Curve25519 pro výměnu klíčů, ChaCha20 pro šifrování a Poly1305 pro autentizaci dat. Funguje také se SipHash pro hash klíče a BLAKE2 pro hash.
ChaCha20-Poly1305 je standardizován pro IPsec a OpenVPN (přes TLS).
Je zřejmé, že vývoj Daniela Bernsteina je využíván velmi často. BLAKE2 je nástupcem BLAKE, finalisty SHA-3, který nevyhrál kvůli své podobnosti s SHA-2. Pokud by byl SHA-2 rozbit, byla velká šance, že by byl kompromitován i BLAKE.
IPsec a OpenVPN nepotřebují SipHash kvůli jejich designu. Takže jediné, co se s nimi aktuálně nedá použít, je BLAKE2, a to jen do té doby, než se to standardizuje. To není velká nevýhoda, protože VPN používají k vytvoření integrity HMAC, což je považováno za silné řešení i ve spojení s MD5.
Došel jsem tedy k závěru, že ve všech VPN se používá téměř stejná sada kryptografických nástrojů. WireGuard proto není více ani méně bezpečný než jakýkoli jiný současný produkt, pokud jde o šifrování nebo integritu přenášených dat.
Ani to ale není to nejdůležitější, čemu se podle oficiální dokumentace projektu vyplatí věnovat pozornost. Koneckonců, hlavní je rychlost.
Je WireGuard rychlejší než jiná řešení VPN?
Stručně řečeno: ne, ne rychleji.
ChaCha20 je proudová šifra, která se snadněji implementuje do softwaru. Šifruje jeden bit po druhém. Blokové protokoly jako AES šifrují blok 128 bitů najednou. K implementaci hardwarové podpory je zapotřebí mnohem více tranzistorů, takže větší procesory jsou dodávány s AES-NI, rozšířením instrukční sady, které provádí některé úkoly šifrovacího procesu za účelem jeho urychlení.
Očekávalo se, že se AES-NI nikdy nedostane do smartphonů [ale stalo se — cca. za.]. Za tímto účelem byl ChaCha20 vyvinut jako lehká alternativa šetřící baterii. Proto vám může přijít jako novinka, že každý smartphone, který si dnes můžete koupit, má nějakou AES akceleraci a s tímto šifrováním běží rychleji a s nižší spotřebou než s ChaCha20.
Je zřejmé, že téměř každý stolní/serverový procesor zakoupený v posledních několika letech má AES-NI.
Proto očekávám, že AES překoná ChaCha20 v každém jednotlivém scénáři. Oficiální dokumentace WireGuard zmiňuje, že s AVX512 ChaCha20-Poly1305 překoná AES-NI, ale toto rozšíření instrukční sady bude dostupné pouze na větších CPU, což opět nepomůže s menším a mobilnějším hardwarem, který bude s AES vždy rychlejší - N.I.
Nejsem si jistý, zda se to dalo při vývoji WireGuardu předvídat, ale dnes už to, že je přibitý k samotnému šifrování, je nevýhodou, která nemusí jeho fungování příliš ovlivnit.
IPsec vám umožňuje svobodně si vybrat, které šifrování je pro váš případ nejlepší. A to je samozřejmě nutné, pokud chcete například přes VPN přenést 10 a více gigabajtů dat.
Problémy s integrací v Linuxu
Přestože WireGuard zvolil moderní šifrovací protokol, už to způsobuje spoustu problémů. A tak namísto použití toho, co je podporováno jádrem ihned po vybalení, byla integrace WireGuardu roky odkládána kvůli nedostatku těchto primitiv v Linuxu.
Nejsem si úplně jistý, jaká je situace na jiných operačních systémech, ale asi se moc neliší od Linuxu.
Jak vypadá realita?
Bohužel pokaždé, když mě klient požádá, abych mu nastavil připojení VPN, narazím na problém, že používají zastaralé přihlašovací údaje a šifrování. 3DES ve spojení s MD5 je stále běžnou praxí, stejně jako AES-256 a SHA1. A i když to druhé je o něco lepší, není to něco, co by se mělo používat v roce 2020.
Pro výměnu klíčů vždy Používá se RSA - pomalý, ale poměrně bezpečný nástroj.
Moji klienti jsou ve spojení s celními úřady a dalšími vládními organizacemi a institucemi, stejně jako s velkými korporacemi, jejichž jména jsou známá po celém světě. Všechny používají formulář žádosti, který byl vytvořen před desítkami let, a možnost používat SHA-512 nebyla prostě nikdy přidána. Nemůžu říct, že to nějak jednoznačně ovlivňuje technologický pokrok, ale evidentně to zpomaluje firemní proces.
Bolí mě, když to vidím, protože IPsec podporuje eliptické křivky od roku 2005. Curve25519 je také novější a k dispozici pro použití. Existují také alternativy k AES jako Camellia a ChaCha20, ale samozřejmě ne všechny jsou podporovány velkými dodavateli, jako je Cisco a další.
A lidé toho využívají. Existuje mnoho sad Cisco, existuje mnoho sad navržených pro práci s Cisco. V tomto segmentu jsou lídry na trhu a o žádné inovace se příliš nezajímají.
Ano, situace [ve firemním segmentu] je strašná, ale kvůli WireGuard se nedočkáme žádných změn. Prodejci pravděpodobně nikdy neuvidí žádné problémy s výkonem u nástrojů a šifrování, které již používají, neuvidí žádné problémy s IKEv2, a proto nehledají alternativy.
Obecně, přemýšleli jste někdy o tom, že byste Cisco opustili?
Srovnávací hodnoty
A nyní přejděme k benchmarkům z dokumentace WireGuard. Ačkoli tato [dokumentace] není vědecký článek, přesto jsem očekával, že vývojáři zaujmou více vědecký přístup nebo použijí vědecký přístup jako referenci. Jakékoli benchmarky jsou k ničemu, pokud je nelze reprodukovat, a ještě k ničemu, když jsou získány v laboratoři.
V linuxovém sestavení WireGuard využívá výhod použití GSO - Generic Segmentation Offloading. Díky němu klient vytvoří obrovský paket o velikosti 64 kilobajtů a zašifruje / dešifruje jej na jeden zátah. Tím se sníží náklady na vyvolání a implementaci kryptografických operací. Pokud chcete maximalizovat propustnost vašeho připojení VPN, je to dobrý nápad.
Jenže, jak už to bývá, realita není tak jednoduchá. Odeslání tak velkého paketu do síťového adaptéru vyžaduje, aby byl rozdělen na mnoho menších paketů. Normální velikost odesílání je 1500 bajtů. To znamená, že náš gigant o velikosti 64 kilobajtů bude rozdělen do 45 paketů (1240 bajtů informací a 20 bajtů hlavičky IP). Pak na chvíli úplně zablokují práci síťového adaptéru, protože se musí poslat společně a najednou. Ve výsledku to povede ke skoku priority a pakety, jako je například VoIP, budou zařazeny do fronty.
Vysoké propustnosti, kterou WireGuard tak směle prohlašuje, je tedy dosaženo za cenu zpomalení síťového propojení ostatních aplikací. A tým WireGuard už je toto je můj závěr.
Ale pojďme dál.
Podle benchmarků v technické dokumentaci připojení vykazuje propustnost 1011 Mbps.
Impozantní.
To je působivé zejména díky skutečnosti, že maximální teoretická propustnost jednoho gigabitového ethernetového připojení je 966 Mbps s velikostí paketu 1500 bajtů mínus 20 bajtů pro hlavičku IP, 8 bajtů pro hlavičku UDP a 16 bajtů pro hlavičku samotný WireGuard. V zapouzdřeném paketu je ještě jedna IP hlavička a další v TCP pro 20 bajtů. Kde se tedy vzala tato extra šířka pásma?
S obrovskými rámečky a výhodami GSO, o kterých jsme mluvili výše, by teoretické maximum pro velikost rámce 9000 bajtů bylo 1014 Mbps. Obvykle je taková propustnost ve skutečnosti nedosažitelná, protože je spojena s velkými obtížemi. Mohu se tedy jen domnívat, že test byl proveden s použitím ještě tlustších předimenzovaných rámců 64 kilobajtů s teoretickým maximem 1023 Mbps, což podporují pouze některé síťové adaptéry. To je ale v reálných podmínkách absolutně nepoužitelné, nebo lze použít pouze mezi dvěma přímo propojenými stanicemi, výhradně v rámci zkušební stolice.
Ale protože VPN tunel je předáván mezi dvěma hostiteli pomocí internetového připojení, které vůbec nepodporuje jumbo snímky, nelze výsledek dosažený na benchmarku brát jako benchmark. To je prostě nereálný laboratorní výkon, který je nemožný a nepoužitelný v reálných bojových podmínkách.
I když jsem seděl v datovém centru, nemohl jsem přenášet snímky větší než 9000 bajtů.
Kritérium použitelnosti v reálném životě je absolutně porušeno a jak se domnívám, autor provedeného "měření" se z pochopitelných důvodů vážně zdiskreditoval.
Poslední záblesk naděje
Na stránkách WireGuard se o kontejnerech hodně mluví a je jasné, k čemu jsou vlastně určeny.
Jednoduchá a rychlá VPN, která nevyžaduje žádnou konfiguraci a lze ji nasadit a konfigurovat pomocí masivních nástrojů pro orchestraci, jako má Amazon ve svém cloudu. Konkrétně Amazon používá nejnovější hardwarové funkce, které jsem zmínil dříve, jako je AVX512. To se provádí za účelem urychlení práce a není vázáno na x86 nebo jinou architekturu.
Optimalizují propustnost a pakety větší než 9000 bajtů – budou to obrovské zapouzdřené rámce pro vzájemnou komunikaci kontejnerů nebo pro operace zálohování, vytváření snímků nebo nasazení stejných kontejnerů. Ani dynamické IP adresy nijak neovlivní fungování WireGuardu v případě mnou popsaného scénáře.
Dobře zahráno. Brilantní implementace a velmi tenký, téměř referenční protokol.
Ale to se prostě nehodí do světa mimo datové centrum, které zcela ovládáte. Pokud to risknete a začnete používat WireGuard, budete muset při návrhu a implementaci šifrovacího protokolu dělat neustálé kompromisy.
Výkon
Je pro mě snadné dojít k závěru, že WireGuard ještě není připraven.
Byl koncipován jako lehké a rychlé řešení řady problémů se stávajícími řešeními. Bohužel kvůli těmto řešením obětoval mnoho funkcí, které budou relevantní pro většinu uživatelů. Proto nemůže nahradit IPsec nebo OpenVPN.
Aby se WireGuard stal konkurenceschopným, potřebuje přidat alespoň nastavení IP adresy a konfiguraci směrování a DNS. K tomu samozřejmě slouží šifrované kanály.
Bezpečnost je mou nejvyšší prioritou a momentálně nemám důvod se domnívat, že IKE nebo TLS jsou nějak kompromitovány nebo poškozeny. V obou je podporováno moderní šifrování, které je prověřené desítkami let provozu. To, že je něco novější, neznamená, že je to lepší.
Interoperabilita je nesmírně důležitá, když komunikujete s třetími stranami, jejichž stanice neřídíte. IPsec je de facto standard a je podporován téměř všude. A on pracuje. A bez ohledu na to, jak to vypadá, teoreticky WireGuard v budoucnu nemusí být kompatibilní ani s různými verzemi sebe sama.
Jakákoli kryptografická ochrana je dříve nebo později narušena, a proto musí být nahrazena nebo aktualizována.
Popírat všechna tato fakta a slepě chtít použít WireGuard k připojení vašeho iPhone k domácí pracovní stanici je prostě mistrovská třída strkání hlavy do písku.
Zdroj: www.habr.com