W ostatnich czasach WireGuard przyciąga dużą uwagę, praktycznie stając się nową „gwiazdą” wśród VPN. Ale czy jest tak dobry, jak się wydaje? Chciałbym omówić pewne obserwacje i przyjrzeć się implementacji WireGuard, aby wyjaśnić, dlaczego nie jest to rozwiązanie, które zastąpi IPsec lub OpenVPN.
W tym artykule chciałbym obalić kilka mitów [wokół WireGuard]. Tak, będzie trzeba dużo przeczytać, więc jeśli jeszcze nie zaparzyłeś sobie filiżanki herbaty lub kawy, to jest najlepszy moment, aby to zrobić. Chciałbym też podziękować Peterowi za poprawki moich chaotycznych myśli.
Nie mam na celu zdyskredytować twórców WireGuard, deprecjonować ich wysiłków ani pomysłów. ich produkt działa, ale osobiście uważam, że jest przedstawiany zupełnie inaczej niż jest w rzeczywistości – jako zamiana dla IPsec i OpenVPN, które tak naprawdę w tej chwili po prostu nie istnieje.
Na marginesie warto dodać, że odpowiedzialność za takie pozycjonowanie WireGuard ponoszą media, które o nim pisały, a nie sam projekt ani jego twórcy.
Ostatnio nie było zbyt wiele dobrych wiadomości na temat jądra Linux. Usłyszeliśmy o potwornych lukach w zabezpieczeniach procesora, które zostały załatane programowo, a Linus Torvalds opowiadał o tym w sposób zbyt szorstki i nudny, językiem używanym przez programistów. Harmonogram czy stos sieciowy zerowego poziomu również nie są zbyt zrozumiałymi tematami dla czasopism. A tu pojawia się WireGuard.
Na papierze wszystko brzmi dobrze: fascynująca nowa technologia.
Ale przyjrzyjmy się jej nieco bliżej.
Dokumentacja techniczna WireGuard
Ten artykuł opiera się na oficjalnej dokumentacji WireGuard, napisana przez Jasona Donenfelda. Tam wyjaśnia koncepcję, cel i techniczną realizację [WireGuard] w jądrze Linux.
Pierwsze zdanie brzmi:
WireGuard […] dąży do zastąpienia zarówno IPsec w większości jego zastosowań, jak i inne popularne rozwiązania oparte na przestrzeni użytkownika i/lub TLS, takie jak OpenVPN, stając się bardziej bezpiecznym, wydajnym i prostym w użyciu [narzędziem].
Oczywiście, główną zaletą wszystkich nowych technologii jest ich prostota [w porównaniu z poprzednikami]. Ale VPN musi być także wydajny i bezpieczny.
Co dalej?
Jeśli powiesz, że potrzebujesz czegoś innego niż [od VPN], to na tym zakończymy czytanie. Zauważę jednak, że takie zadania są stawiane przed każdą inną technologią tunelowania.
Najciekawsze w powyższej cytacie kryje się w słowach „w większości przypadków”, które, naturalnie, zostały zignorowane przez prasę. I oto jesteśmy tam, gdzie znaleźliśmy się z powodu tego chaotycznego zaniedbania — w tym artykule.
Czy WireGuard stanie się zamiennikiem mojego połączenia VPN [IPsec] między stronami?
Nie. Po prostu nie ma szans, że duzi dostawcy, tacy jak Cisco, Juniper i inni, zaadoptują WireGuard do swoich produktów. Nie skaczą „na mijające pociągi” w biegu, jeśli nie ma ku temu jakiejś konkretnej potrzeby. Później opowiem o kilku powodach, dla których prawdopodobnie nie będą w stanie wdrożyć WireGuard w swoich produktach, nawet jeśli by chcieli.
Czy WireGuard przeniesie mojego RoadWarriora z laptopa do centrum danych?
Nie. W tej chwili WireGuard nie ma wielu ważnych funkcji, które pozwoliłyby mu zrobić coś takiego. Na przykład, nie może korzystać z dynamicznych adresów IP po stronie serwera tunelu, a już to łamie cały scenariusz takiego zastosowania produktu.
IPFire często używa się w tanich kanałach internetowych, na przykład w DSL lub połączeniu kablowym. To ma sens dla małych lub średnich firm, które nie potrzebują szybkiego światłowodu. [Uwaga od tłumacza: nie należy zapominać, że w zakresie łączności Rosja i niektóre kraje WNP są daleko przed Europą i USA, ponieważ zaczęliśmy budować nasze sieci znacznie później i z przybyciem Ethernetu oraz światłowodów jako standardu, łatwiej było nam się przystosować. W tych krajach UE czy USA, dostęp szerokopasmowy xDSL o prędkości 3-5 Mb/s — wciąż jest powszechną normą, a podłączenie światłowodowe kosztuje jakiekolwiek, nierealne w naszym rozrachunku pieniądze. Dlatego autor artykułu mówi o połączeniach DSL lub kablowych jako o normie, a nie o staromodnych metodach.] Jednak połączenia DSL, kablowe, LTE (i inne bezprzewodowe metody dostępu) mają dynamiczne adresy IP. Oczywiście, czasami zmieniają się one rzadko, ale jednak się zmieniają.
Istnieje podprojekt o nazwie „wg-dynamic”, który dodaje demon przestrzeni użytkownika, aby przezwyciężyć tę wadę. Ogromnym problemem scenariusza użytkowego opisanego powyżej jest pogarszająca się sytuacja z dynamicznym adresowaniem IPv6.
Z perspektywy dystrybutora to również nie wygląda najlepiej. Jednym z celów rozwoju było zachowanie prostoty i czystości protokołu.
Niestety, wszystko to stało się na tyle proste i prymitywne, że musimy korzystać z dodatkowego oprogramowania, aby cała ta konstrukcja była żywotna w rzeczywistych warunkach eksploatacji.
Czy łatwo jest korzystać z WireGuard?
Na razie nie. Nie twierdzę, że WireGuard nigdy nie będzie dobrą alternatywą do tunelowania między dwoma punktami, ale jak na razie to tylko wersja alfa produktu, którym powinien się stać.
Ale co on naprawdę robi? Czy IPsec jest rzeczywiście tak wiele bardziej skomplikowany w eksploatacji?
Oczywiście, że nie. Dostawca IPsec przewidział ten aspekt i dostarcza swój produkt z interfejsem, na przykład z IPFire.
Aby skonfigurować tunel VPN poprzez IPsec, potrzebujesz pięciu zestawów danych, które należy wprowadzić do konfiguracji: twój własny publiczny adres IP, publiczny adres IP strony odbierającej, podsieci, które chcesz udostępnić poprzez to połączenie VPN, oraz klucz pre-shared. W ten sposób VPN jest konfigurowany w ciągu kilku minut i jest kompatybilny z każdym dostawcą.
Niestety, w tej historii są pewne wyjątki. Każdy, kto próbował skonfigurować tunel VPN przez IPsec do maszyny na OpenBSD, wie, o czym mówię. Jest jeszcze kilka bolesnych przykładów, ale tak naprawdę pozytywnych praktyk korzystania z IPsec jest znacznie więcej.
O złożoności protokołu
Końcowy użytkownik nie powinien martwić się o złożoność protokołu.
Gdybyśmy żyli w świecie, w którym to byłoby prawdziwym zmartwieniem użytkowników, dawno pozbylibyśmy się SIP, H.323, FTP i innych protokołów stworzonych ponad dziesięć lat temu, które źle radzą sobie z NAT.
Są powody, dla których IPsec jest bardziej skomplikowany niż WireGuard: robi znacznie więcej rzeczy. Na przykład, uwierzytelnienie użytkownika przy użyciu loginu/hasła lub karty SIM z EAP. Ma rozszerzone możliwości dodawania nowych prymitywów kryptograficznych.
A WireGuard tego nie ma.
Oznacza to, że WireGuard w pewnym momencie może ulec awarii, ponieważ jeden z elementów kryptograficznych osłabnie lub zostanie całkowicie skompromitowany. Autor dokumentacji technicznej mówi o tym w ten sposób:
Warto zauważyć, że WireGuard jest kryptograficznie pewny siebie. Intencjonalnie brakuje mu elastyczności szyfrów i protokołów. Jeśli w podstawowych elementach zostaną wykryte poważne luki, należy zaktualizować wszystkie punkty końcowe. Jak widać z ciągłego strumienia podatności SSL/TLS, elastyczność szyfrowania znacznie wzrosła.
Ostatnie zdanie jest całkowicie prawdziwe.
Osiągnięcie konsensusu co do tego, jakie szyfrowanie zastosować, sprawia, że protokoły takie jak IKE i TLS ponad są skomplikowane. Zbyt skomplikowane? Tak, w TLS/SSL podatności występują dość często, a alternatyw dla nich nie ma.
O ignorowaniu rzeczywistych problemów
Wyobraź sobie, że masz serwer VPN z 200 aktywnymi klientami rozmieszczonymi po całym świecie. To całkiem standardowy scenariusz użycia. Jeśli będziesz musiał zmienić szyfrowanie, musisz dostarczyć aktualizację do wszystkich kopii WireGuard na tych laptopach, smartfonach i tak dalej. Jednocześnie dostarczanie. To jest dosłownie niemożliwe. Administratorzy, którzy spróbują to zrobić, będą potrzebowali miesięcy na wdrożenie niezbędnych konfiguracji, a średnim firmom do tego przedsięwzięcia dosłownie potrzebne będą lata.
IPsec i OpenVPN oferują funkcję negocjacji szyfrów. Dlatego w pewnym czasie, po którym włączysz nowe szyfrowanie, starsze również będzie działać. Dzięki temu aktualni klienci mogą zaktualizować swój oprogramowanie. Po wdrożeniu aktualizacji po prostu wyłączysz podatne szyfrowanie. I wszystko! Gotowe! Jesteś wspaniały! A klienci nawet tego nie zauważą.
To naprawdę bardzo powszechny przypadek dla dużych wdrożeń, a nawet OpenVPN napotyka w tym pewne trudności. Kompatybilność wsteczna jest ważna, a choć używasz słabszego szyfrowania, dla wielu nie jest to powód do zamknięcia działalności. Ponieważ doprowadzi to do paraliżu pracy setek klientów z powodu braku możliwości wykonywania swojej pracy.
Zespół WireGuard uprościł swój protokół, ale jest zupełnie nieodpowiedni dla osób, które nie mają stałej kontroli nad oboma węzłami swojego tunelu. Z mojego doświadczenia wynika, że taki scenariusz jest najczęściej spotykany.
Kryptografia!
Ale cóż to za interesujące nowe szyfrowanie, które wykorzystuje WireGuard?
WireGuard używa Curve25519 do wymiany kluczy, ChaCha20 do szyfrowania i Poly1305 do uwierzytelniania danych. Działa również z SipHash do kluczy hashujących i BLAKE2 do haszowania.
ChaCha20-Poly1305 jest standardyzowany dla IPsec i OpenVPN (przez TLS).
Oczywiście, rozwój Daniela Bernsteina jest wykorzystywany bardzo często. BLAKE2 jest następcą BLAKE, finalistą SHA-3, który nie wygrał z powodu swojej podobieństwa do SHA-2. Gdyby SHA-2 zostało złamane, istniałoby duże prawdopodobieństwo, że również BLAKE byłby skompromitowany.
IPsec i OpenVPN nie potrzebują SipHash ze względu na ich projekt. Tak więc, jedyną rzeczą, która obecnie nie może być używana z nimi, jest BLAKE2, i to tylko do czasu, aż zostanie on znormalizowany. To nie jest duża wada, ponieważ VPN-y używają HMAC do zapewnienia integralności, co uważa się za silne rozwiązanie nawet w połączeniu z MD5.
Zatem doszedłem do wniosku, że w prawie wszystkich VPN używany jest ten sam zestaw narzędzi kryptograficznych. Dlatego WireGuard nie jest ani bardziej, ani mniej bezpieczny niż jakiekolwiek inne aktualne produkty, gdy chodzi o szyfrowanie lub integralność przesyłanych danych.
Jednak to nie jest najważniejsze, na co warto zwrócić uwagę według oficjalnej dokumentacji projektu. Najważniejsza jest szybkość.
Czy WireGuard jest szybszy niż inne rozwiązania VPN?
Krótko mówiąc: nie, nie jest szybszy.
ChaCha20 to szyfr strumieniowy, który łatwiej wdrożyć w oprogramowaniu. Szyfruje jeden bit na raz. Protokoły blokowe, takie jak AES, szyfrują blok po 128 bitów na raz. Wdrożenie wsparcia sprzętowego wymaga znacznie więcej tranzystorów, dlatego większe procesory są wyposażane w AES-NI — rozszerzenie zestawu instrukcji, które wykonuje niektóre zadania procesu szyfrowania w celu jego przyspieszenia.
Oczekiwano, że AES-NI nigdy nie trafi do smartfonów [a jednak trafił, — przypis red.]. Dlatego opracowano ChaCha20 jako lekką i oszczędną alternatywę, szanującą żywotność baterii. Może być zaskoczeniem, że każdy smartfon, który możesz dzisiaj kupić, ma jakieś przyspieszenie dla AES i działa z tym szyfrowaniem szybciej oraz z mniejszym zużyciem energii niż ChaCha20.
Oczywiście, że praktycznie każdy procesor do komputerów stacjonarnych / serwerów kupiony w ciągu ostatnich kilku lat ma AES-NI.
W związku z tym oczekuję, że AES przewyższy ChaCha20 w każdym pojedynczym scenariuszu. W oficjalnej dokumentacji WireGuard wspomniano, że dzięki AVX512 ChaCha20-Poly1305 przewyższy AES-NI, ale to rozszerzenie zestawu instrukcji będzie dostępne tylko na dużych procesorach, co ponownie nie pomoże na mniejszych i mobilnych urządzeniach, które zawsze będą działać szybciej z AES-NI.
Nie jestem pewien, czy to można było przewidzieć przy opracowywaniu WireGuard, ale dzisiaj fakt, że jest on przywiązany do jednego szyfrowania, już stanowi wadę, która może negatywnie wpłynąć na jego działanie.
IPsec pozwala na swobodny wybór, które szyfrowanie najlepiej pasuje do twojego przypadku. I oczywiście jest to niezbędne, jeśli chcesz przesłać 10 i więcej gigabajtów danych przez połączenie VPN.
Problemy z integracją w Linuxie
Choć WireGuard wybrał nowoczesny protokół szyfrowania, już powoduje to wiele problemów. Zamiast korzystać z tego, co jest wspierane przez jądro od ręki, integracja WireGuard była odkładana przez lata z powodu braku tych prymitywów w Linuxie.
Nie jestem do końca na bieżąco z sytuacją w innych systemach operacyjnych, ale prawdopodobnie nie różni się ona zbytnio od sytuacji w Linuxie.
Jak wygląda rzeczywistość?
Niestety, za każdym razem, gdy klient prosi mnie o skonfigurowanie połączenia VPN, napotykam problem, że używają przestarzałych danych uwierzytelniających i szyfrowania. 3DES w połączeniu z MD5 to wciąż powszechna praktyka, podobnie jak AES-256 i SHA1. I chociaż ten ostatni jest nieco lepszy — to nie jest coś, z czego warto korzystać w 2020 roku.
Do wymiany kluczy zawsze używa się RSA — wolnego, ale wystarczająco bezpiecznego narzędzia.
Moi klienci mają do czynienia z organami celnymi oraz innymi instytucjami rządowymi i agencjami, a także z dużymi korporacjami, których nazwy są znane na całym świecie. Wszyscy oni korzystają z formularza zapytania, który został stworzony dekady temu, a możliwość wykorzystania SHA-512 nigdy nie została dodana. Nie mogę powiedzieć, że w jakiś sposób wpływa to na postęp technologiczny, ale oczywiste jest, że spowalnia to procesy korporacyjne.
Boli mnie to widzieć, ponieważ IPsec wspiera krzywe eliptyczne od roku 2005. Curve25519 jest również nowszy i dostępny do użytku. Są też alternatywy dla AES, takie jak Camellia i ChaCha20, ale oczywiście nie wszystkie z nich są wspierane przez dużych dostawców, takich jak Cisco i inni.
I ludzie z tego korzystają. Istnieje wiele zestawów Cisco, jest wiele zestawów stworzonych do pracy z Cisco. Są liderami rynku w tym segmencie i niespecjalnie interesują się innowacjami.
Tak, sytuacja [w segmencie korporacyjnym] jest straszna, ale nie zobaczymy żadnych zmian z powodu WireGuard. Producenci prawdopodobnie nigdy nie dostrzegą jakichkolwiek problemów z wydajnością obecnie wykorzystywanego oprogramowania i szyfrowania, nie zauważą problemów z użyciem IKEv2 — i dlatego nie szukają alternatyw.
Czy kiedykolwiek zastanawiałeś się nad rezygnacją z Cisco?
Benchmarki
A teraz przejdźmy do benchmarków z dokumentacji WireGuard. Choć ta [dokumentacja] nie jest pracą naukową, nadal oczekiwałem od deweloperów bardziej naukowego podejścia, albo użycia podejścia naukowego jako punktu odniesienia. Jakiekolwiek benchmarki są bezwartościowe, jeśli nie można ich odtworzyć, a jeszcze bardziej bezwartościowe, gdy są uzyskane w warunkach laboratoryjnych.
W wersji WireGuard dla systemu Linux zyskuje on przewagę, stosując GSO — Generic Segmentation Offloading. Dzięki temu, klient tworzy ogromny pakiet o rozmiarze 64 kilobajtów i szyfruje/dekryptuje go za jednym podejściem. W ten sposób koszty wywołań i realizacji operacji kryptograficznych są redukowane. Jeśli chcesz zmaksymalizować przepustowość swojego połączenia VPN — to dobry pomysł.
Jednak, jak to zazwyczaj bywa, w rzeczywistości nie jest to takie proste. Wysłanie tak dużego pakietu do adaptera sieciowego wymaga, aby został on podzielony na wiele mniejszych pakietów. Typowy rozmiar wysyłanego pakietu wynosi 1500 bajtów. Oznacza to, że nasz gigant o wielkości 64 kilobajtów zostanie podzielony na 45 pakietów (1240 bajtów informacji i 20 bajtów nagłówka IP). Następnie, na pewien czas, całkowicie zablokują działanie adaptera sieciowego, ponieważ muszą być wysłane razem i jednocześnie. W rezultacie doprowadzi to do skoku priorytetu, a takie pakiety jak VoIP będą czekały w kolejce.
W ten sposób wysoka przepustowość, o której tak śmiało twierdzi WireGuard, osiągana jest kosztem spowolnienia działania sieci innych aplikacji. I zespół WireGuard już potwierdziła ten mój wniosek.
Ale przejdźmy dalej.
Zgodnie z benchmarkami w dokumentacji technicznej, połączenie wykazuje przepustowość wynoszącą 1011 Mbit/s.
Imponujące.
Szczególnie imponujące jest to, że maksymalna teoretyczna przepustowość jednego gigabitowego połączenia Ethernet wynosi 966 Mbit/s przy rozmiarze pakietu 1500 bajtów minus 20 bajtów na nagłówek IP, 8 bajtów na nagłówek UDP i 16 bajtów na nagłówek samego WireGuard. Jest jeszcze jeden nagłówek IP w pakiecie enkapsulowanym i inny nagłówek w TCP o rozmiarze 20 bajtów. Skąd więc wzięła się ta dodatkowa przepustowość?
Przy ogromnych ramkach i korzyściach z GSO, o których wspomnieliśmy powyżej, teoretyczny maksymalny rozmiar ramki wynoszący 9000 bajtów będzie równy 1014 Mbit/s. Zazwyczaj taka przepustowość w rzeczywistości jest nieosiągalna, ponieważ wiąże się z dużymi trudnościami. Dlatego mogę tylko przypuszczać, że test został przeprowadzony z wykorzystaniem jeszcze większych ramek z przekroczeniem rozmiaru 64 kilobajty z teoretycznym maksymalnym rozmiarem wynoszącym 1023 Mbit/s, co jest obsługiwane tylko przez niektóre adaptery sieciowe. Ale to jest absolutnie niepraktyczne w warunkach rzeczywistych lub może być używane tylko między dwoma bezpośrednio połączonymi stacjami, wyłącznie w ramach stoiska testowego.
Jednakże, ponieważ tunel VPN jest tworzony między dwoma hostami za pomocą połączenia internetowego, które w ogóle nie obsługuje dużych ram, osiągnięty na stanowisku wynik nie może być przyjęty jako wzór. To po prostu nierealne osiągnięcie laboratoryjne, które jest niemożliwe i niepraktyczne w rzeczywistych warunkach bojowych.
Nawet siedząc w centrum danych, nie mógłbym przesyłać ramek większych niż 9000 bajtów.
Kryterium przydatności w rzeczywistości zostało całkowicie naruszone i, jak sądzę, autor przeprowadzonego „pomiaru” poważnie skompromitował siebie z oczywistych powodów.
Ostatni promyk nadziei
Na stronie WireGuard dużo mówi się o kontenerach i staje się jasne, do czego tak naprawdę jest przeznaczony.
Prosty i szybki VPN, który nie wymaga konfiguracji i może być wdrażany oraz konfigurowany masowymi narzędziami orkiestracyjnymi, takimi jak na przykład w chmurze Amazon. Konkretne Amazon wykorzystuje najnowsze funkcje sprzętowe, o których wspominałem wcześniej, takie jak AVX512. Robi się to, aby przyspieszyć pracę i nie przywiązywać się do architektury x86 lub jakiejkolwiek innej.
Optymalizują przepustowość i pakiety, których rozmiar przekracza 9000 bajtów — to będą ogromne enkapsulowane ramki do komunikacji między kontenerami, lub do operacji tworzenia kopii zapasowych, tworzenia zrzutów stanu czy uruchamiania tych samych kontenerów. Nawet dynamiczne adresy IP w żaden sposób nie wpłyną na działanie WireGuard w opisanym przeze mnie scenariuszu.
Nieźle zagrane. Błyskotliwa realizacja i bardzo subtelny, niemal wzorcowy protokół.
Ale po prostu nie nadaje się do świata poza w pełni kontrolowanym przez ciebie centrum danych. Jeśli jednak zaryzykujesz i zaczniesz używać WireGuard, będziesz musiał zadowolić się ciągłymi kompromisami w projektowaniu i wdrażaniu protokołu szyfrowania.
Wnioski
Nie trudno mi wyciągnąć wniosek, że WireGuard na razie nie jest gotowy.
Został zaprojektowany jako uproszczone i szybkie rozwiązanie szeregu problemów istniejących rozwiązań. Niestety, w imię tych rozwiązań poświęcił wiele funkcji, które będą istotne dla większości użytkowników. Dlatego właśnie 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, właśnie do tego potrzebne są szyfrowane kanały.
Bezpieczeństwo jest moim głównym priorytetem i obecnie nie mam podstaw, by sądzić, że IKE lub TLS są jakoś skompromitowane lub uszkodzone. Oba mają współczesne szyfrowanie, które zostało przetestowane przez dziesięciolecia eksploatacji. To, że coś jest nowsze, nie znaczy, że jest lepsze.
Funkcjonalna kompatybilność jest niezwykle ważna, gdy łączysz się z podmiotami trzecimi, których stacji nie kontrolujesz. IPsec jest de facto standardem i jest wspierany praktycznie wszędzie. I działa. I choć może to wydawać się teoretyczne, w przyszłości WireGuard może być niekompatybilny nawet z różnymi wersjami samego siebie.
Każda kryptograficzna ochrona prędzej czy później zostaje złamana i dlatego musi być wymieniana lub aktualizowana.
Zaprzeczanie tym faktom i ślepe pragnienie używania WireGuard do łączenia swojego iPhone'a z domową stacją roboczą to po prostu mistrzostwo w wkładaniu głowy w piasek.
Źródło: habr.com
