WireGuard cieszy się ostatnio dużym zainteresowaniem, w rzeczywistości jest nową gwiazdą wśród VPN. Ale czy jest tak dobry, jak się wydaje? Chciałbym omówić kilka spostrzeżeń i dokonać przeglądu implementacji WireGuard, aby wyjaśnić, dlaczego nie jest to rozwiązanie zastępujące IPsec lub OpenVPN.
W tym artykule chciałbym obalić niektóre mity [wokół WireGuard]. Tak, czytanie zajmie dużo czasu, więc jeśli nie zrobiłeś sobie filiżanki herbaty lub kawy, czas to zrobić. Chciałbym również podziękować Piotrowi za skorygowanie moich chaotycznych myśli.
Nie stawiam sobie za cel dyskredytowania twórców WireGuarda, dewaluowania ich wysiłków czy pomysłów. Ich produkt działa, ale osobiście uważam, że jest przedstawiony zupełnie inaczej niż jest w rzeczywistości - jest przedstawiany jako zamiennik dla IPsec i OpenVPN, który w rzeczywistości po prostu teraz nie istnieje.
Na marginesie dodam, że odpowiedzialność za takie pozycjonowanie WireGuarda spoczywa na mediach, które o tym mówiły, a nie na samym projekcie czy jego twórcach.
Ostatnio nie było dobrych wiadomości na temat jądra Linuksa. Powiedziano nam więc o monstrualnych słabościach procesora, które zostały zniwelowane przez oprogramowanie, a Linus Torvalds mówił o tym zbyt niegrzecznie i nudno, w utylitarnym języku dewelopera. Harmonogram lub stos sieciowy zerowego poziomu również nie są zbyt jasnymi tematami dla błyszczących magazynów. I tu pojawia się WireGuard.
Na papierze wszystko brzmi świetnie: ekscytująca nowa technologia.
Ale spójrzmy na to trochę bliżej.
Biała księga WireGuarda
Ten artykuł jest oparty na napisany przez Jasona Donenfelda. Tam wyjaśnia koncepcję, cel i techniczną implementację [WireGuard] w jądrze Linuksa.
Pierwsze zdanie brzmi:
WireGuard […] ma na celu zastąpienie zarówno IPsec w większości przypadków użycia, jak i innych popularnych rozwiązań opartych na przestrzeni użytkownika i/lub TLS, takich jak OpenVPN, będąc jednocześnie bezpieczniejszym, wydajniejszym i łatwiejszym w użyciu [narzędzie].
Oczywiście główną zaletą wszystkich nowych technologii jest ich prostota [w porównaniu do poprzedników]. Ale VPN też powinien być wydajne i bezpieczne.
Więc co dalej?
Jeśli powiesz, że to nie jest to, czego potrzebujesz [z VPN], możesz zakończyć czytanie tutaj. Zaznaczę jednak, że takie zadania są ustawione dla każdej innej technologii tunelowania.
Najciekawszy z powyższego cytatu zawiera się w słowach „w większości przypadków”, które oczywiście zostały zignorowane przez prasę. I tak oto znaleźliśmy się tam, gdzie wylądowaliśmy z powodu chaosu wywołanego przez to zaniedbanie - w tym artykule.
Czy WireGuard zastąpi moją sieć VPN typu site-to-site [IPsec]?
NIE. Po prostu nie ma szans, aby duzi dostawcy, tacy jak Cisco, Juniper i inni, kupili WireGuard dla swoich produktów. Nie „wskakują na przejeżdżające pociągi” w ruchu, chyba że jest ku temu wielka potrzeba. Później omówię niektóre powody, dla których prawdopodobnie nie będą mogli wprowadzić swoich produktów WireGuard na pokład, nawet gdyby chcieli.
Czy WireGuard przeniesie mój RoadWarrior z laptopa do centrum danych?
NIE. W tej chwili WireGuard nie ma zaimplementowanej ogromnej liczby ważnych funkcji, aby móc zrobić coś takiego. Na przykład nie może używać dynamicznych adresów IP po stronie serwera tunelu i już samo to przekreśla cały scenariusz takiego wykorzystania produktu.
IPFire jest często używany do tanich łączy internetowych, takich jak DSL lub połączenia kablowe. Ma to sens w przypadku małych i średnich firm, które nie potrzebują szybkiego światłowodu. [Uwaga od tłumacza: nie zapominajmy, że pod względem komunikacji Rosja i niektóre kraje WNP znacznie wyprzedzają Europę i Stany Zjednoczone, ponieważ zaczęliśmy budować nasze sieci dużo później i wraz z pojawieniem się sieci Ethernet i światłowodowych jako standard, łatwiej było nam odbudować. W tych samych krajach UE czy USA szerokopasmowy dostęp xDSL o prędkości 3-5 Mb/s jest nadal powszechną normą, a połączenie światłowodowe kosztuje jakieś nierealne jak na nasze standardy pieniądze. Dlatego autor artykułu mówi o połączeniu DSL lub kablowym jako o normie, a nie o starożytności.] Jednak DSL, kabel, LTE (i inne metody dostępu bezprzewodowego) mają dynamiczne adresy IP. Oczywiście czasami nie zmieniają się one często, ale jednak się zmieniają.
Istnieje podprojekt o nazwie , który dodaje demona przestrzeni użytkownika w celu przezwyciężenia tego niedociągnięcia. Ogromnym problemem związanym z opisanym powyżej scenariuszem użytkownika jest pogorszenie dynamicznego adresowania IPv6.
Z punktu widzenia dystrybutora to wszystko też nie wygląda najlepiej. Jednym z celów projektowych było zachowanie prostoty i przejrzystości protokołu.
Niestety, to wszystko stało się w rzeczywistości zbyt proste i prymitywne, przez co musimy korzystać z dodatkowego oprogramowania, aby cały ten projekt nadawał się do rzeczywistego użytku.
Czy WireGuard jest tak łatwy w użyciu?
Jeszcze nie. Nie twierdzę, że WireGuard nigdy nie będzie dobrą alternatywą do tunelowania między dwoma punktami, ale na razie jest to tylko wersja alfa produktu, którym powinna być.
Ale co wtedy właściwie robi? Czy IPsec jest naprawdę dużo trudniejszy w utrzymaniu?
Oczywiście, że nie. Dostawca IPsec pomyślał o tym i dostarcza swój produkt wraz z interfejsem, takim jak IPFire.
Aby skonfigurować tunel VPN przez IPsec, będziesz potrzebować pięciu zestawów danych, które będziesz musiał wprowadzić do konfiguracji: własny publiczny adres IP, publiczny adres IP strony odbierającej, podsieci, które chcesz upublicznić za pośrednictwem to połączenie VPN i klucz wstępny. W ten sposób sieć VPN jest konfigurowana w ciągu kilku minut i jest kompatybilna z dowolnym dostawcą.
Niestety, w tej historii jest kilka wyjątków. Każdy, kto próbował tunelować przez IPsec do maszyny OpenBSD, wie o czym mówię. Istnieje kilka bardziej bolesnych przykładów, ale w rzeczywistości istnieje o wiele więcej dobrych praktyk dotyczących korzystania z protokołu IPsec.
O złożoności protokołu
Użytkownik końcowy nie musi martwić się o złożoność protokołu.
Gdybyśmy żyli w świecie, w którym użytkownik naprawdę by się tym przejmował, pozbylibyśmy się SIP, H.323, FTP i innych protokołów stworzonych ponad dziesięć lat temu, które nie działają dobrze z NAT.
Istnieją powody, dla których IPsec jest bardziej złożony niż WireGuard: robi o wiele więcej rzeczy. Na przykład uwierzytelnienie użytkownika za pomocą loginu/hasła lub karty SIM z EAP. Posiada rozszerzoną możliwość dodawania nowych .
A WireGuard tego nie ma.
A to oznacza, że WireGuard w pewnym momencie się zepsuje, ponieważ jeden z prymitywów kryptograficznych osłabnie lub zostanie całkowicie skompromitowany. Autor dokumentacji technicznej mówi tak:
Warto zauważyć, że WireGuard jest kryptograficznie opiniotwórczy. Celowo brakuje mu elastyczności szyfrów i protokołów. Jeśli w elementach podstawowych zostaną znalezione poważne dziury, wszystkie punkty końcowe będą musiały zostać zaktualizowane. Jak widać na podstawie ciągłego strumienia luk w zabezpieczeniach SLL/TLS, elastyczność szyfrowania ogromnie wzrosła.
Ostatnie zdanie jest jak najbardziej poprawne.
Osiągnięcie konsensusu co do tego, jakiego szyfrowania użyć, sprawia, że protokoły takie jak IKE i TLS więcej złożony. Zbyt skomplikowane? Tak, luki są dość powszechne w TLS/SSL i nie ma dla nich alternatywy.
O ignorowaniu prawdziwych problemów
Wyobraź sobie, że masz serwer VPN z 200 klientami bojowymi gdzieś na całym świecie. Jest to dość standardowy przypadek użycia. Jeśli musisz zmienić szyfrowanie, musisz dostarczyć aktualizację do wszystkich kopii WireGuard na tych laptopach, smartfonach i tak dalej. Jednocześnie dostarczać. To dosłownie niemożliwe. Administratorzy próbujący to zrobić będą potrzebować miesięcy na wdrożenie wymaganych konfiguracji, a średniej wielkości firmie dosłownie lata na przeprowadzenie takiego zdarzenia.
IPsec i OpenVPN oferują funkcję negocjacji szyfrów. Dlatego przez pewien czas, po którym włączysz nowe szyfrowanie, stare również będzie działać. Umożliwi to obecnym klientom uaktualnienie do nowej wersji. Po wdrożeniu aktualizacji wystarczy wyłączyć podatne na ataki szyfrowanie. I to wszystko! Gotowy! jesteś wspaniały! Klienci nawet tego nie zauważą.
W rzeczywistości jest to bardzo częsty przypadek w przypadku dużych wdrożeń i nawet OpenVPN ma z tym pewne trudności. Kompatybilność wsteczna jest ważna i nawet jeśli używasz słabszego szyfrowania, dla wielu nie jest to powód do zamknięcia firmy. Ponieważ sparaliżuje pracę setek klientów z powodu niemożności wykonywania swojej pracy.
Zespół WireGuard uprościł swój protokół, ale jest całkowicie bezużyteczny dla osób, które nie mają stałej kontroli nad obydwoma rówieśnikami w swoim tunelu. Z mojego doświadczenia wynika, że jest to najczęstszy scenariusz.
Kryptografia!
Ale czym jest to interesujące nowe szyfrowanie, którego używa WireGuard?
WireGuard używa Curve25519 do wymiany kluczy, ChaCha20 do szyfrowania i Poly1305 do uwierzytelniania danych. Działa również z SipHash dla kluczy mieszających i BLAKE2 dla mieszania.
ChaCha20-Poly1305 jest standaryzowany dla IPsec i OpenVPN (przez TLS).
Oczywiste jest, że bardzo często wykorzystuje się rozwinięcie Daniela Bernsteina. BLAKE2 jest następcą BLAKE, finalisty SHA-3, który nie wygrał ze względu na podobieństwo do SHA-2. Gdyby SHA-2 miał zostać złamany, istniała duża szansa, że BLAKE również zostałby naruszony.
IPsec i OpenVPN nie potrzebują SipHash ze względu na ich konstrukcję. Tak więc jedyną rzeczą, której obecnie nie można z nimi używać, jest BLAKE2, i to tylko do czasu ujednolicenia. Nie jest to duża wada, ponieważ sieci VPN używają HMAC do tworzenia integralności, co jest uważane za mocne rozwiązanie nawet w połączeniu z MD5.
Doszedłem więc do wniosku, że we wszystkich sieciach VPN używany jest prawie ten sam zestaw narzędzi kryptograficznych. Dlatego WireGuard nie jest ani bardziej, ani mniej bezpieczny niż jakikolwiek inny obecny produkt, jeśli chodzi o szyfrowanie lub integralność przesyłanych danych.
Ale nawet to nie jest najważniejsze, na co według oficjalnej dokumentacji projektu warto zwrócić uwagę. W końcu najważniejsza jest szybkość.
Czy WireGuard jest szybszy niż inne rozwiązania VPN?
Krótko mówiąc: nie, nie szybciej.
ChaCha20 to szyfr strumieniowy, który jest łatwiejszy do wdrożenia w oprogramowaniu. Szyfruje jeden bit na raz. Protokoły blokowe, takie jak AES, szyfrują blok 128 bitów na raz. Do implementacji wsparcia sprzętowego potrzeba znacznie więcej tranzystorów, więc większe procesory są dostarczane z AES-NI, rozszerzeniem zestawu instrukcji, które wykonuje niektóre zadania procesu szyfrowania, aby go przyspieszyć.
Spodziewano się, że AES-NI nigdy nie trafi do smartfonów [ale tak się stało — ok. za.]. W tym celu ChaCha20 został opracowany jako lekka, oszczędzająca baterię alternatywa. Dlatego może być dla ciebie nowością, że każdy smartfon, który możesz dziś kupić, ma jakąś akcelerację AES i działa szybciej i przy mniejszym zużyciu energii z tym szyfrowaniem niż z ChaCha20.
Oczywiście prawie każdy procesor do komputerów stacjonarnych/serwerów kupiony w ciągu ostatnich kilku lat ma AES-NI.
Dlatego oczekuję, że AES przewyższy ChaCha20 w każdym scenariuszu. Oficjalna dokumentacja WireGuard wspomina, że z AVX512, ChaCha20-Poly1305 przewyższy AES-NI, ale to rozszerzenie zestawu instrukcji będzie dostępne tylko na większych procesorach, co znowu nie pomoże w przypadku mniejszego i bardziej mobilnego sprzętu, który zawsze będzie szybszy z AES - N.I.
Nie jestem pewien, czy można było to przewidzieć podczas opracowywania WireGuard, ale dziś fakt, że jest on przybity do samego szyfrowania, jest już wadą, która może nie wpływać zbyt dobrze na jego działanie.
IPsec pozwala swobodnie wybrać, które szyfrowanie jest najlepsze w Twoim przypadku. I oczywiście jest to konieczne, jeśli na przykład chcesz przesłać 10 lub więcej gigabajtów danych przez połączenie VPN.
Problemy z integracją w systemie Linux
Chociaż WireGuard wybrał nowoczesny protokół szyfrowania, powoduje to już wiele problemów. I tak, zamiast korzystać z tego, co jest obsługiwane przez jądro po wyjęciu z pudełka, integracja WireGuard została opóźniona o lata z powodu braku tych prymitywów w Linuksie.
Nie jestem do końca pewien, jak wygląda sytuacja w innych systemach operacyjnych, ale prawdopodobnie niewiele się różni od Linuksa.
Jak wygląda rzeczywistość?
Niestety, za każdym razem, gdy klient prosi mnie o skonfigurowanie dla niego połączenia VPN, napotykam problem polegający na tym, że używają nieaktualnych danych uwierzytelniających i szyfrowania. 3DES w połączeniu z MD5 jest nadal powszechną praktyką, podobnie jak AES-256 i SHA1. I choć to drugie jest nieco lepsze, to nie jest to coś, z czego należy korzystać w 2020 roku.
Do wymiany kluczy zawsze Używane jest RSA - powolne, ale dość bezpieczne narzędzie.
Moi klienci są związani z organami celnymi oraz innymi organizacjami i instytucjami rządowymi, a także z dużymi korporacjami, których nazwy są znane na całym świecie. Wszyscy korzystają z formularza wniosku, który powstał kilkadziesiąt lat temu, a możliwość korzystania z SHA-512 po prostu nigdy nie została dodana. Nie mogę powiedzieć, że jakoś wyraźnie wpływa to na postęp technologiczny, ale oczywiście spowalnia proces korporacyjny.
Boli mnie to, ponieważ IPsec obsługuje krzywe eliptyczne od 2005 roku. Curve25519 jest również nowszy i dostępny do użytku. Istnieją również alternatywy dla AES, takie jak Camellia i ChaCha20, ale oczywiście nie wszystkie z nich są obsługiwane przez głównych dostawców, takich jak Cisco i inni.
I ludzie to wykorzystują. Istnieje wiele zestawów Cisco, istnieje wiele zestawów zaprojektowanych do pracy z Cisco. Są liderami rynku w tym segmencie i nie są zbytnio zainteresowani jakąkolwiek innowacją.
Tak, sytuacja [w segmencie korporacyjnym] jest fatalna, ale przez WireGuard nie zobaczymy żadnych zmian. Dostawcy prawdopodobnie nigdy nie zobaczą żadnych problemów z wydajnością narzędzi i szyfrowania, których już używają, nie zobaczą żadnych problemów z IKEv2, więc nie szukają alternatyw.
Ogólnie, czy kiedykolwiek myślałeś o porzuceniu Cisco?
Wzorce
A teraz przejdźmy do testów porównawczych z dokumentacji WireGuard. Chociaż ta [dokumentacja] nie jest artykułem naukowym, nadal spodziewałem się, że twórcy przyjmą bardziej naukowe podejście lub użyją podejścia naukowego jako odniesienia. Wszelkie wzorce są bezużyteczne, jeśli nie można ich odtworzyć, a jeszcze bardziej bezużyteczne, gdy są uzyskiwane w laboratorium.
W Linuksowej wersji WireGuard korzysta z GSO - Generic Segmentation Offloading. Dzięki niemu klient tworzy ogromny pakiet o wielkości 64 kilobajtów i szyfruje/odszyfrowuje go za jednym razem. W ten sposób zmniejsza się koszt wywoływania i wdrażania operacji kryptograficznych. Jeśli chcesz zmaksymalizować przepustowość połączenia VPN, jest to dobry pomysł.
Jednak jak zwykle rzeczywistość nie jest taka prosta. Wysłanie tak dużego pakietu do karty sieciowej wymaga podzielenia go na wiele mniejszych pakietów. Normalny rozmiar wysyłania to 1500 bajtów. Oznacza to, że nasz gigant 64 kilobajtów zostanie podzielony na 45 pakietów (1240 bajtów informacji i 20 bajtów nagłówka IP). Wtedy na jakiś czas całkowicie zablokują pracę karty sieciowej, ponieważ muszą być wysłane razem i jednocześnie. W rezultacie doprowadzi to do przeskoku priorytetów, a pakiety, takie jak na przykład VoIP, zostaną umieszczone w kolejce.
Tak więc wysoka przepustowość, którą WireGuard tak odważnie deklaruje, jest osiągana kosztem spowolnienia działania sieci innych aplikacji. A zespół WireGuard już jest to jest moja konkluzja.
Ale przejdźmy dalej.
Według benchmarków w dokumentacji technicznej łącze wykazuje przepustowość 1011 Mbps.
Imponujący.
Jest to tym bardziej imponujące, że maksymalna teoretyczna przepustowość pojedynczego połączenia Gigabit Ethernet wynosi 966 Mb/s przy wielkości pakietu 1500 bajtów minus 20 bajtów dla nagłówka IP, 8 bajtów dla nagłówka UDP i 16 bajtów dla nagłówka samego WireGuarda. W hermetyzowanym pakiecie jest jeszcze jeden nagłówek IP, a drugi w TCP na 20 bajtów. Skąd więc wzięła się ta dodatkowa przepustowość?
Przy ogromnych ramkach i zaletach GSO, o których mówiliśmy powyżej, teoretyczne maksimum dla rozmiaru ramki 9000 bajtów wynosiłoby 1014 Mb/s. Zwykle taka przepustowość jest w rzeczywistości nieosiągalna, ponieważ wiąże się z dużymi trudnościami. Mogę więc jedynie założyć, że test został przeprowadzony przy użyciu jeszcze grubszych, przewymiarowanych ramek o wielkości 64 kilobajtów z teoretycznym maksimum 1023 Mb/s, co jest obsługiwane tylko przez niektóre karty sieciowe. Ale jest to absolutnie nie do zastosowania w rzeczywistych warunkach lub może być używane tylko między dwiema bezpośrednio połączonymi stacjami, wyłącznie w obrębie stanowiska badawczego.
Ale ponieważ tunel VPN jest przekazywany między dwoma hostami za pomocą połączenia internetowego, które w ogóle nie obsługuje ramek jumbo, wyniku uzyskanego na stanowisku nie można traktować jako punktu odniesienia. Jest to po prostu nierealne osiągnięcie laboratoryjne, niemożliwe i nie do zastosowania w rzeczywistych warunkach bojowych.
Nawet siedząc w centrum danych nie mogłem przesyłać ramek większych niż 9000 bajtów.
Kryterium stosowalności w życiu jest bezwzględnie naruszone i jak sądzę autor przeprowadzonego „pomiaru” poważnie się zdyskredytował z oczywistych względów.
Ostatni promyk nadziei
Witryna WireGuard dużo mówi o kontenerach i staje się jasne, do czego tak naprawdę jest przeznaczona.
Prosta i szybka sieć VPN, która nie wymaga konfiguracji i może być wdrożona i skonfigurowana za pomocą ogromnych narzędzi do orkiestracji, takich jak Amazon w swojej chmurze. W szczególności Amazon wykorzystuje najnowsze funkcje sprzętowe, o których wspomniałem wcześniej, takie jak AVX512. Odbywa się to w celu przyspieszenia pracy i braku powiązania z architekturą x86 lub inną.
Optymalizują przepustowość i pakiety większe niż 9000 bajtów - będą to ogromne enkapsulowane ramki do komunikowania się kontenerów ze sobą lub do operacji tworzenia kopii zapasowych, tworzenia migawek lub wdrażania tych samych kontenerów. Nawet dynamiczne adresy IP nie wpłyną w żaden sposób na działanie WireGuarda w przypadku opisanego przeze mnie scenariusza.
Dobrze rozegrane. Znakomita implementacja i bardzo cienki, niemal referencyjny protokół.
Ale to po prostu nie pasuje do świata poza centrum danych, które całkowicie kontrolujesz. Jeśli podejmiesz ryzyko i zaczniesz używać WireGuard, będziesz musiał iść na ciągłe kompromisy w projektowaniu i wdrażaniu protokołu szyfrowania.
Wniosek
Łatwo mi dojść do wniosku, że WireGuard nie jest jeszcze gotowy.
Został pomyślany jako lekkie i szybkie rozwiązanie wielu problemów z istniejącymi rozwiązaniami. Niestety na rzecz tych rozwiązań poświęcił wiele funkcji, które będą istotne dla większości użytkowników. Dlatego nie może zastąpić IPsec ani OpenVPN.
Aby WireGuard stał się konkurencyjny, musi dodać przynajmniej ustawienie adresu IP oraz konfigurację routingu i DNS. Oczywiście do tego służą kanały szyfrowane.
Bezpieczeństwo jest moim najwyższym priorytetem iw tej chwili nie mam powodu sądzić, że IKE lub TLS są w jakiś sposób zagrożone lub zepsute. Oba obsługują nowoczesne szyfrowanie, które zostało sprawdzone przez dziesięciolecia działania. To, że coś jest nowsze, nie oznacza, że jest lepsze.
Interoperacyjność jest niezwykle ważna, gdy komunikujesz się ze stronami trzecimi, których stacjami nie kontrolujesz. IPsec jest de facto standardem i jest obsługiwany prawie wszędzie. I on pracuje. I bez względu na to, jak to wygląda, w teorii WireGuard w przyszłości może nie być kompatybilny nawet z różnymi wersjami samego siebie.
Każda ochrona kryptograficzna prędzej czy później zostanie zerwana i w związku z tym musi zostać wymieniona lub zaktualizowana.
Zaprzeczanie wszystkim tym faktom i ślepe pragnienie użycia WireGuard do podłączenia iPhone'a do domowej stacji roboczej to tylko mistrzowska klasa w chowaniu głowy w piasek.
Źródło: www.habr.com