V poslední době si WireGuard získává velkou pozornost, fakticky — je to nová „hvězda“ mezi VPN. Ale je opravdu tak dobrý, jak se zdá? Rád bych prodiskutoval některé poznatky a podíval se na implementaci WireGuard, abych vysvětlil, proč není řešením, které by nahradilo IPsec nebo OpenVPN.
V tomto článku bych chtěl vyvrátit některé mýty [kolem WireGuard]. Ano, čtení bude dlouhé, takže pokud jste si ještě neuvařili šálek čaje nebo kávy, teď je ten pravý čas. Také bych chtěl poděkovat Peterovi za korekturu mých chaotických myšlenek.
Nemám v úmyslu diskreditovat vývojáře WireGuard, znehodnotit jejich úsilí nebo myšlenky. Jejich produkt je funkční, ale osobně si myslím, že je prezentován úplně jinak, než ve skutečnosti je — představován jako náhrada IPsec a OpenVPN, které v současnosti prostě neexistuje.
Jako poznámku chci dodat, že odpovědnost za takové pozicování WireGuard nese média, která o něm hovořila, nikoli samotný projekt nebo jeho tvůrci.
V poslední době nebylo kolem jádra Linuxu příliš mnoho dobrých zpráv. Tak nám vyprávěli o strašlivých zranitelných místech procesoru, která byla zmírněna softwarově, a Linus Torvalds o tom hovořil 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š srozumitelná témata pro lesklé časopisy. A tady se objevuje WireGuard.
Na papíře to všechno zní skvěle: fascinující nová technologie.
Ale podívejme se na ni trochu blíže.
Technická dokumentace WireGuard
Tento článek je založen na oficiální dokumentace WireGuard, kterou napsal Jason Donenfeld. Tam vysvětluje koncept, cíl a technickou realizaci [WireGuard] v jádře Linuxu.
První věta zní:
WireGuard […] se snaží nahradit jak IPsec v drtivé většině případů jeho použití, tak další populární řešení založená na uživatelském prostoru a/nebo TLS, jako například OpenVPN, přičemž je více bezpečným, výkonným a jednoduše použitelným [nástrojem].
Samozřejmě, hlavní výhodou všech nových technologií je jejich jednoduchost [v porovnání s předchůdci]. Ale VPN by také měl být účinný a bezpečný.
A co dál?
Pokud řeknete, že potřebujete něco jiného než [od VPN], pak je čtení tímto ukončeno. Nicméně bych si rád poznamenal, že takové úkoly jsou kladeny před každou jinou tunnelingovou technologii.
Nejdůležitější z výše uvedeného citátu spočívá ve slovech «ve většině případů», která se samozřejmě médiím podařilo ignorovat. A jsme tam, kde jsme kvůli vytvořenému tímto nedbalostí chaosu — v tomto článku.
Bude WireGuard náhradou za moje [IPsec] VPN spojení mezi weby?
Ne. Zde není žádná šance, že by velcí dodavatelé, jako Cisco, Juniper a další, implementovali WireGuard do svých produktů. Ne ‚skáčí do projíždějících vlaků‘, pokud k tomu není nějaká velká potřeba. Později vám vysvětlím některé důvody, proč pravděpodobně nebudou schopni integrovat WireGuard do svých produktů, i kdyby chtěli.
Přenese WireGuard mého RoadWarriora z notebooku do datového centra?
Ne. V tuto chvíli WireGuard neimplementuje velké množství důležitých funkcí, které by mu umožnily něco takového udělat. Například nemůže používat dynamické IP adresy na straně serveru tunelu, a to už samo o sobě narušuje celý scénář takového použití produktu.
IPFire se často používá pro levné internetové kanály, jako je DSL nebo kabelové připojení. Dává to smysl pro malé nebo střední podniky, které nepotřebují rychlou optiku. [Poznámka překladatele: nezapomínejte, že v oblasti připojení je Rusko a některé země SNS daleko před Evropou a USA, protože jsme začali budovat své sítě mnohem později a s příchodem Ethernetu a optických sítí jako standardu, bylo pro nás snazší se přeorientovat. V těchto zemích EU nebo USA je xDSL širokopásmový přístup s rychlostí 3-5 Mbit/s stále běžnou normou, zatímco optické připojení stojí astronomické částky. Proto autor článku hovoří o DSL nebo kabelovém připojení jako o normě, nikoli o starožitnosti.] Nicméně DSL, kabelové, LTE (a další bezdrátové metody přístupu) mají dynamické IP adresy. Samozřejmě, že se občas mění, i když ne často, ale stále se mění.
Existuje podpoložka s názvem „wg-dynamic“, který přidává demonstrační uživatelský prostor k překonání této nevýhody. Obrovským problémem uživatelského scénáře popsaného výše je zhoršení situace dynamickým IPv6 adresováním.
Z pohledu distributora to také nevypadá příliš dobře. Jedním z cílů vývoje bylo zachovat jednoduchost a čistotu protokolu.
Bohužel, to vše se skutečně stalo příliš jednoduché a primitivní, takže musíme používat další software, aby byla tato konstrukce životaschopná v reálném provozu.
Je WireGuard tak snadné používat?
Zatím ne. Neříkám, že WireGuard nikdy nebude dobrou alternativou pro tunelování mezi dvěma body, ale zatím je to pouze alfa-verze produktu, kterým by měl být.
Ale co tedy skutečně dělá? Je IPsec opravdu tak složitější na provoz?
Zjevně ne. Poskytovatel IPsec tento aspekt promyslel a dodává svůj produkt spolu s rozhraním, například s IPFire.
Pro nastavení VPN tunelu přes IPsec budete potřebovat pět sad údajů, které je třeba zadat do konfigurace: vaši vlastní veřejnou IP adresu, veřejnou IP adresu přijímající strany, podsítě, které chcete zpřístupnit přes toto VPN spojení, a pre-shared klíč. Takto se VPN nastaví během několika minut a je kompatibilní s jakýmkoliv dodavatelem.
Bohužel, v tomto příběhu existuje několik výjimek. Každý, kdo se pokusil tunelovat VPN přes IPsec k zařízení na OpenBSD, ví, o čem mluvím. Existuje ještě několik bolestivých příkladů, ale ve skutečnosti je pozitivní praxe používání IPsec mnohem víc.
O složitosti protokolu
Konečný uživatel by se neměl obávat složitosti protokolu.
Kdybychom žili ve světě, kde by to byla skutečná starost uživatele, už dávno bychom se zbavili SIP, H.323, FTP a dalších protokolů, které byly vytvořeny před více než deseti lety a špatně fungují s NAT.
Existují důvody, proč je IPsec složitější než WireGuard: dělá mnohem více věcí. Například ověřování uživatele pomocí přihlašovacího jména/hesla nebo SIM karty s EAP. Má rozšířené možnosti přidávání nových kryptografických primitivů.
Ale WireGuard to nemá.
A to znamená, že WireGuard se v určitém okamžiku porouchá, protože jeden z kryptografických primitivů oslabí nebo bude zcela kompromitován. Autor technické dokumentace o tom říká toto:
Je třeba poznamenat, že WireGuard je kryptograficky sebevědomý. Záměrně mu chybí flexibilita šifer a protokolů. Pokud budou v základních primitivech nalezeny vážné mezery, všechny koncové body bude třeba aktualizovat. Jak je vidět z neustálého toku zranitelností SLL/TLS, flexibilita šifrování se nyní enormně zvýšila.
Poslední tvrzení je zcela pravdivé.
Dosažení konsensu o tom, které šifrování použít, činí protokoly jako IKE a TLS více než složitými. Příliš složitými? Ano, v TLS/SSL se zranitelnosti vyskytují dost často a alternativy k nim nejsou.
O ignorování skutečných problémů
Představte si, že máte VPN server s 200 aktivními klienty rozmístěnými po celém světě. To je poměrně běžný scénář použití. Pokud bude nutné změnit šifrování, budete muset doručit aktualizaci na všechny instance WireGuard na těchto noteboocích, smartphonech a tak dále. Současně doručit. To je doslova nemožné. Správcům, kteří se o to pokusí, budou potřebné měsíce na nasazení potřebných konfigurací, a průměrným firmám to doslova zabere roky na realizaci takového úkolu.
IPsec a OpenVPN nabízejí funkci vyjednávání šifer. Proto nějakou dobu, po které aktivujete nové šifrování, bude fungovat i staré. Díky tomu mohou aktuální klienti přejít na novou verzi. Jakmile bude aktualizace rozšířena, prostě vypnete zranitelné šifrování. A je to! Hotovo! Jste úžasní! A klienti si toho ani nevšimnou.
Ve skutečnosti je to velmi běžný případ pro velká nasazení a i OpenVPN má s tímto některé 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í podnikání. Protože by to vedlo k paralyzování práce stovek klientů kvůli neschopnosti vykonávat svou práci.
Tým WireGuard zjednodušil svůj protokol, avšak je zcela nevhodný pro lidi, kteří nemají stálou kontrolu nad oběma uzly svého tunelu. Z mé zkušenosti je právě tento scénář nejběžnější.
Kryptografie!
Ale jaké zajímavé nové šifrování používá WireGuard?
WireGuard využívá Curve25519 pro výměnu klíčů, ChaCha20 pro šifrování a Poly1305 pro autentizaci dat. Také pracuje se SipHash pro hashovací klíče a BLAKE2 pro hashování.
ChaCha20-Poly1305 je standardizován pro IPsec a OpenVPN (přes TLS).
Je zřejmé, že vývoj Daniela Bernsteina je velmi často používán. BLAKE2 je nástupcem BLAKE, finalisty SHA-3, který nevyhrál kvůli svému podobnosti se SHA-2. Pokud by byla SHA-2 prolomena, existovala by vysoká pravděpodobnost, že i BLAKE by byl kompromitován.
IPsec a OpenVPN nepotřebují SipHash kvůli svému designu. Takže jediné, co v současnosti nemůže být s nimi použito, je BLAKE2, a to pouze do doby, než bude standardizován. To není velké mínus, protože VPN používají HMAC k vytvoření integrity, což je považováno za silné řešení i v kombinaci s MD5.
Tak jsem došel k závěru, že v téměř všech VPN se používá prakticky stejná sada kryptografických nástrojů. Proto WireGuard není bezpečnější ani méně bezpečný než jakékoli jiné aktuální produkty, pokud jde o šifrování nebo integritu přenášených dat.
Ale ani to není nejdůležitější, na co by se mělo podle oficiální dokumentace projektu zaměřit. Hlavní je totiž rychlost.
Je WireGuard rychlejší než ostatní VPN řešení?
Pokud to shrnu: ne, není rychlejší.
ChaCha20 je proudové šifrování, které se snadněji implementuje do softwaru. Šifruje jeden bit za čas. Blokové protokoly, jako AES, šifrují blok po 128 bitech najednou. Pro implementaci hardwarové podpory je potřeba mnohem více tranzistorů, takže větší procesory jsou dodávány s AES-NI — rozšířením sady instrukcí, které provádí některé úkoly procesu šifrování pro jeho zrychlení.
Očekávalo se, že AES-NI se nikdy nedostane do chytrých telefonů [ale dostal, — pozn. překl.]. K tomu byl vyvinut ChaCha20 jako lehká a úsporná alternativa šetřící baterii. Proto pro vás může být překvapením, že každý chytrý telefon, který můžete dnes zakoupit, má nějakou formu akcelerace pro AES a pracuje s tímto šifrováním rychleji a s menší spotřebou energie než s ChaCha20.
Je zřejmé, že prakticky každý procesor pro stolní PC / servery zakoupený v posledních dvou letech má AES-NI.
Proto očekávám, že AES překoná ChaCha20 v každém jednotlivém scénáři. V oficiální dokumentaci WireGuard se uvádí, že díky AVX512 bude ChaCha20-Poly1305 překonávat AES-NI, ale tato rozšíření příkazového systému budou dostupná pouze na větších procesorech, což opět nepomůže menším a mobilním zařízením, které vždy budou rychleji pracovat s AES-NI.
Nejsem si jistý, zda to šlo předvídat při vývoji WireGuard, ale dnes je fakt, že je přibit k jednomu šifrování — už nedostatkem, který může negativně ovlivnit jeho výkon.
IPsec umožňuje volbu toho, které šifrování nejlépe vyhovuje vašemu případu. A samozřejmě, to je nutné, pokud například chcete přenést 10 a více gigabajtů dat přes VPN spojení.
Problémy integrace v Linuxu
Ačkoli WireGuard zvolil moderní šifrovací protokol, to už způsobuje spoustu problémů. A tak místo toho, abychom použili to, co je nativně podporováno jádrem, byla integrace WireGuard odkládána roky kvůli absenci těchto primitiv v Linuxu.
Nejsem úplně v obraze, jaká je situace v jiných operačních systémech, ale pravděpodobně se příliš neliší od situace v Linuxu.
Jak vypadá realita?
Bohužel, pokaždé, když mě klient požádá o nastavení VPN spojení, narazím na téma, že používají zastaralé přihlašovací údaje a šifrování. 3DES v kombinaci s MD5 — je stále rozšířenou praxí, stejně jako AES-256 a SHA1. A i když je ten poslední trochu lepší — to není něco, co byste měli používat v roce 2020.
Pro výměnu klíčů vždy se používá RSA — pomalý, ale dostatečně bezpečný nástroj.
Moji klienti se propojují s celními úřady a dalšími státními orgány a institucemi, stejně jako s velkými korporacemi, jejichž názvy jsou známé po celém světě. Všichni používají formulář žádosti, který byl vytvořen před desetiletími, a možnost použití SHA-512 jednoduše nikdy nebyla přidána. Nemohu říct, že by to nějak výrazně ovlivnilo technologický pokrok, ale je zřejmé, že to zpomaluje korporátní procesy.
Bolí mě to vidět, protože IPsec podporuje eliptické křivky zhruba od roku 2005. Curve25519 je také novější a k dispozici pro použití. Existují alternativy k AES, jako je Camellia a ChaCha20, ale zřejmě ne všechny z nich jsou podporovány velkými dodavateli, jako je Cisco a další.
A lidé to používají. Existuje mnoho sad Cisco, existuje množství sad navržených pro práci s Cisco. Jsou lídry na trhu v tomto segmentu a o žádné inovace příliš zájem nemají.
Ano, situace [v korporátním segmentu] je hrozná, ale žádné změny kvůli WireGuard neuvidíme. Výrobci pravděpodobně nikdy neodhalí žádné problémy s výkonem již používaného nástroje a šifrování, neuvidí problémy při používání IKEv2 — a proto nehledají alternativy.
Vůbec, někdy jste přemýšleli o ukončení spolupráce s Cisco?
Benchmarky
A nyní se přesuňme k benchmarkům z dokumentace WireGuard. I když tato [dokumentace] není vědecký článek, očekával jsem od vývojářů více vědecký přístup, nebo použití vědeckého přístupu jako vzoru. Jakékoli benchmarky jsou k ničemu, pokud nejsou reprodukovatelné, a ještě více jsou k ničemu, když jsou získány v laboratorních podmínkách.
Ve verzi WireGuard pro Linux získává výhodu pomocí GSO — Generic Segmentation Offloading. Díky tomu klient vytváří obrovský paket o velikosti 64 kilobajtů a šifruje/odešifruje ho na jeden zátah. Tím se snižují náklady na volání a realizaci kryptografických operací. Pokud chcete maximalizovat propustnost vašeho VPN připojení — to je dobrý nápad.
Jak to obvykle bývá, v reálu to není tak jednoduché. Odeslání tak velkého balíku na síťový adaptér vyžaduje, aby byl rozdělen na mnoho menších balíků. Běžná velikost odesílaného balíku je 1500 bajtů. To znamená, že náš gigant o velikosti 64 kilobajtů bude rozdělen na 45 balíků (1240 bajtů informací a 20 bajtů IP hlavičky). Poté na nějakou dobu zcela zablokují práci síťového adaptéru, protože musí být odeslány společně a okamžitě. Výsledkem bude skok priorit, což způsobí, že balíky jako VoIP budou čekat v řadě.
Takto vysoká šířka pásma, kterou WireGuard tak odvážně uvádí, je dosahována zpomalením síťového provozu jiných aplikací. A tým WireGuard již potvrdil toto je moje závěrečné hodnocení.
Ale pojďme se posunout dál.
Podle benchmarků v technické dokumentaci ukazuje spojení šířku pásma 1011 Mbit/s.
Impozantní.
Zvlášť impozantní je to, protože maximální teoretická šířka pásma jednoho gigabitového Ethernet připojení činí 966 Mbit/s při velikosti paketu 1500 bajtů, minus 20 bajtů za IP hlavičku, 8 bajtů za UDP hlavičku a 16 bajtů za hlavičku samotného WireGuardu. Existuje ještě jedna IP hlavička v enkapsulovaném paketu a další - v TCP na 20 bajtů. Tak odkud pochází tato dodatečná šířka pásma?
S obrovskými rámci a výhodami GSO, o kterých jsme mluvili výše, bude teoretický maximální výkon při velikosti rámce 9000 bajtů činit 1014 Mbit/s. Obvykle je tato šířka pásma v reálu nedosažitelná, protože je spojena s velkými obtížemi. Můžu jen předpokládat, že test byl proveden s použitím ještě robustnějších rámců s překročením velikosti 64 kilobajtů s teoretickým maximem 1023 Mbit/s, což podporuje pouze některé síťové adaptéry. Ale to je naprosto nepraktické v reálných podmínkách, nebo může být použito pouze mezi dvěma přímo propojenými stanicemi, výhradně v rámci testovacího prostředí.
Ale protože je VPN-tunel vytvořen mezi dvěma hostiteli pomocí internetového připojení, které obecně nepodporuje velké rámce, dosažený výsledek na testu nemůže být považován za standard. Je to prostě nerealizovatelné laboratorní dosažení, které je nemožné a nepoužitelné v reálných podmínkách.
I když bych byl v datovém centru, nedokázal bych přenášet rámce větší než 9000 bajtů.
Kritérium použitelnosti v reálném životě je naprosto porušeno a, jak si myslím, autor provedeného 'měření' se vážně diskreditoval z pochopitelných důvodů.
Poslední záblesk naděje
Na webu WireGuard se hodně mluví o kontejnerech a je jasné, k čemu je skutečně určen.
Jednoduchý a rychlý VPN, který nevyžaduje konfiguraci a může být nasazen a nastaven masivními nástroji orchestrace, jako například u Amazonu v jejich cloudu. Konkrétně Amazon využívá nejnovější hardwarové funkce, o kterých jsem již zmínil, jako jsou AVX512. To se dělá, aby se zrychlila práce a nevázala se na architekturu x86 nebo jakoukoli jinou.
Optimalizují propustnost a pakety, jejichž velikost přesahuje 9000 bajtů — to budou obrovské zapouzdřené rámy pro komunikaci mezi kontejnery, nebo pro operace zálohování, vytváření snímků nebo nasazení těchto kontejnerů. Dokonce ani dynamické IP adresy nijak neovlivní fungování WireGuard ve výše popsaném scénáři.
Dobře zahráno. Skvělá implementace a velmi jemný, téměř příkladný protokol.
Ale prostě se nehodí pro svět za hranicemi plně kontrolovaného datového centra. Pokud se však odvážíte a začnete používat WireGuard, budete muset přijmout trvalé kompromisy při návrhu a implementaci šifrovacího protokolu.
Výstup
Není pro mě obtížné udělat závěr, že WireGuard zatím není připraven.
Byl navržen jako zjednodušené a rychlé řešení řady problémů stávajících řešení. Bohužel, kvůli těmto řešením obětoval mnohé funkce, které budou relevantní pro většinu uživatelů. Právě 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. Je zřejmé, že právě pro toto jsou potřeba šifrované kanály.
Bezpečnost je mou nejvyšší prioritou, a v současnosti nemám důvod věřit, že by IKE nebo TLS byly nějak kompromitovány nebo porušeny. Moderní šifrování je podpořeno oběma a byla ověřena desítkami let provozu. To, že je něco novější, neznamená, že je to lepší.
Funkční kompatibilita je extrémně důležitá, když se spojujete s třetími stranami, jejichž stanice nekontrolujete. IPsec de facto představuje standard a je téměř všeobecně podporován. A funguje. Ačkoliv to možná v teorii vypadá, WireGuard může v budoucnu být nekompatibilní i s různými verzemi samotného sebe.
Jakákoli kryptografická ochrana bude dříve či později prolomena a tedy musí být nahrazena nebo aktualizována.
Popírání všech těchto faktů a slepé touhy používat WireGuard k připojení vašeho iPhone k domácí pracovní stanici je doslova mistrovské dílo v zasouvání hlavy do písku.
Zdroj: habr.com
