Podkast 22T35 WireGuard VPN – Koniec IPSec i SSL VPN?

WERSJA TEKSTOWA

Cześć. Witam Cię w dzisiejszym odcinku, dzisiaj o WireGuard -najnowszym podejściu do tuneli VPN-owych. Czym jest w ogóle koncepcja tego produktu? Jest to VPN-owa aplikacja Open Source do łączenia ze sobą w sposób bezpieczny dwóch urządzeń. W założeniu ma być szybsza niż IPsec, szybsza niż OpenVPN, prostsza w implementacji a dzięki temu bezpieczniejsza. Zobaczmy czy to faktycznie jest ten etap, w którym te wszystkie założenia są spełnione. Jeżeli chodzi o zalety, czyli szybkość wykorzystywania czy szyfrowania tych danych i przesyłania, wyniki, które widziałem do tej pory pokazują, że w porównaniu do IPsec AES-GCM to jest mniej więcej 10% zysku. Jest trochę szybszy, ale bez jakiś fundamentalnych zmian.

W przypadku OpenVPN-a trzeba pamiętać, że jest on po prostu SSL VPN-em, czyli tak naprawdę TLS VPN-em. W związku z tym działa na warstwie wyższej, zawiera TCP i generalnie jest dużo wolniejszy. Porównując więc go do WireGuarda jest on mniej więcej dwukrotnie szybszym protokołem. Nie jest to generalnie zaskoczeniem, ponieważ w przypadku IPsec-a jest podobnie. IPsec jest znacznie szybszy niż OpenVPN.

Jakie są kolejne zalety? Jedną z głównych, która jest podkreślana jest zaleta bardzo prostej implementacji. Protokół ten nie zawiera bardzo skomplikowanych koncepcji, schematów i warstw. Jest on bardzo prosty i bezpośrednio związany z tym jak najłatwiej zaimplementować dany protokół. Twórca pisze, że cała implementacja jest to 4000 linijek kodu. Patrząc na dzisiejszą specyfikę programowania bardzo nie dużo. Z tego wynika łatwość analizy kodu, czyli szukania potencjalnych podatności i dzięki temu ten protokół ma być bezpieczniejszy. Porównując implementację do IPsec-a, który jest złożony z dwóch faz, negocjacji kluczy dla każdej fazy, wymiany informacji, zestawienia AES – jest nieporównywalnie prostszy. Natomiast czy nas to interesuje jako użytkowników końcowych? Ja patrzę bardziej ze strony typowego użytkownika najczęściej zarządzającego takim dostępem, bardziej z punktu widzenia administracyjnego. Dla mnie ta część implementacyjna o ile nie muszę jej robić ręcznie, czyli nie muszę sam tworzyć zestawów dla IPsec AES, dla fazy pierwszej, dla IKE i fazy drugiej IPsec-owej, to generalnie nie ma żadnego znaczenia. Część audytowa również nie ma dla mnie żadnego znaczenia, ponieważ nie ja robię te audyty. Nie wnikam w kod IPsec-a, OpenVPN-a czy też WireGuarda. Dla mnie ten element nie jest jakiś specjalnie atrakcyjny. Szybkość, nawet jeżeli daje 10% zysk z prędkości jest rzeczą, nad którą można się zastanowić i ją wykorzystać.

Jeszcze jeden element, który będzie kluczowy, jeśli pojawi się szersza implementacja w rozwiązaniach komercyjnych tego protokołu, to kwestia obciążenia koncentratora. W przypadku gdy mówimy o rozwiązaniach komercyjnych, gdzie mamy dużo użytkowników, którzy się podłączają zdalnie to jest pytanie czy możemy ich obsłużyć w liczbie tysiąca, dwóch, dziesięciu tysięcy i jakby to wyglądało w trybie np. OpenVPN-a (SSL VPN-a) i w trybie IPsec-a. To jest coś, co mnie interesuje. Jak wybieram rozwiązanie dla danego zastosowania to patrzę na to jakie aplikacje mam mieć potencjalnie dostępne przez tego VPN-a, jaki oczekuję volumen ruchu i ilu użytkowników będzie równolegle korzystało z danego rozwiązania. Dzięki temu jestem w stanie dobrać odpowiedni poziom wydajności koncentratora. Tutaj, jeżeli chodzi o WireGuarda jest to element, który potencjalnie wydaje się bardzo atrakcyjny. Powinien pozwolić nam na terminowanie dużo większej ilości użytkowników. wykorzystując ten protokół. Jakie ma wady? Przede wszystkim jest nadal określany jako implementacja eksperymentalna. Oznacza to, że do zastosowań takich indywidualnych – jeśli ktoś chce, do zastosowań laboratoryjnych – ok. Natomiast do zastosowań komercyjnych – jeszcze nie.

Z tym się również wiąże taki aspekt braku publikacji do bazy CVE (Common Vulnerabilities and Exposures). To element, który jest niewątpliwie dużym minusem. Wiemy już od tego, który tworzy ten cały protokół, że nie jest to jeszcze wersja stabilna. Wiemy też, że nawet jeślibyśmy chcieli zweryfikować w stosunku do tej bazy informacje o podatnościach to nie znajdziemy tam żadnych informacji o tym protokole. Po prostu nie jest tam jeszcze publikowany zestaw podatności ze względu na to, że to nie jest stabilna wersja. W związku z tym na razie nam jeszcze pozostaje chwilę poczekać. Zobaczymy jak szybko ten protokół powinien się pojawić w naszym administracyjnym świecie. Wygląda na to, że się pojawi i że jest duże zainteresowanie tym protokołem. Ma on swoje zalety. Z punktu widzenia działania powinien dać nam pewne korzyści.

Teraz kilka słów na temat koncepcji działania tego protokołu. Jest ona bardzo podobna do spinania tuneli SSH w wykorzystaniu kluczy prywatnych i publicznych. W przypadku WireGuarda mamy powiązanie klucza publicznego z danym IP do którego będzie dany pakiet wysyłany. Gdy następuje zmiana adresów to wystarczy w pliku, który trzyma tą informację o powiązaniach, wymienić informację powiązania nowego adresu IP z danym kluczem publicznym. To element, który jest sercem całego konceptu jak szyfrować dane. Kolejnym elementem jest brak negocjacji. W tym konkretnie przykładzie, przy WireGuardzie założenie jest takie, że nie ma wysyłanych pakietów innych niż z informacjami o danych. Tutaj mamy bardzo ograniczony element wzajemnej wymiany informacji o tym co wspiera dana końcówka – tak jak w IPsec-u lub SSH. Mamy tu bardzo ograniczony element narzutu dodatkowego na negocjacje, co generalnie – jeżeli wystarczy na spełnienie wymagań – jest założeniem dobrym. Założenie „im prościej, tym lepiej”, jeśli spełnia nasze oczekiwania, jest jak najbardziej dobrym kierunkiem. Trzeba też sobie zdawać sprawę z tego, że koncepcja całego framework-u IPsec-owego, dwuetapowego elementu negocjacji, nie wzięła się znikąd. Jest to framework, który sprawdza się przez kilka ostatnich kilkadziesiąt lat więc jest to element, który na pewno działa. Z drugiej strony nie mamy tego przy WireGuardzie ale też nie wiemy do końca z jakim trudnościami przyjdzie nam się mierzyć w przyszłości.

Pokazując pierwszy przykład z brzegu: element, który omawiałem tydzień temu, czyli możliwość zmiany pewnych parametrów np w protokole TCP. W ramach pewnych rozszerzeń jest bardzo problematyczna dlatego, że ilość implementacji na rynku danego protokołu i zakresu jego implementacji jest potem hamulcem w zmianach. Jeśli mamy na całym świecie miliardy urządzeń, które wspierają dany typ protokołu, jego sposób funkcjonowania – a potrzebujemy tylko pewne elementy zaktualizować np. tylko algorytmy szyfrowania, to jest to coś co możemy zrobić w ramach protokołu. Gdy nie mamy tak bardzo rozbudowanych warstw i możliwości późniejszej aktualizacji tego frameworku, to jest to w pewnym momencie dla nas ograniczeniem. W przypadku WireGuarda wygląda mi na to, że nie będzie to na pewno problemem przy pewnych klasach zastosowań. Natomiast w przypadku innych scenariuszy, które nie były pierwotnie brane pod uwagę przy projektowaniu tego protokołu, już może okazać się, że nie będzie to takie łatwe.

Kolejnym problematycznym przynajmniej na dziś elementem implementacji WireGuarda jest wsparcie tego protokołu na systemach Windows. Ponieważ jak większość protokołów Open Source, protokół ten bierze się od strony Linuxa i wsparcia czy pisania tego kodu na takich systemach, to przenoszenie tego na systemy Windows jest najczęściej kolejnym krokiem, fazą. Tutaj trzeba wspomnieć o tym, że wydajność protokołu WireGuard jest bezpośrednio związana z tym, jak integruje się z danym kernelem. Tutaj zaczynamy mówić o innym poziomie trudności, jeśli mówimy o przenoszeniu tej funkcjonalności do Windowsa. Jeżeli to zostanie zrobione, a tak zapewne będzie, bo jak inaczej realizować powszechny dostęp VPN-owy bez klienta Windows, to zobaczymy jaka będzie wydajność takiej implementacji. W oparciu o Windowsa. Tu już jest zupełnie inny koncept tego jądra systemu i pytanie jaka jest możliwość integracji tego rozwiązania z Windowsem. Prawdopodobnie będzie to związane z tym na ile Microsoft udostępni wsparcie dla tego typu funkcjonalności w swoim systemie. Zobaczymy, jak to będzie w przyszłości funkcjonowało. Natomiast jest to niewątpliwie temat, który warto śledzić. WireGuard będzie się pojawiał w różnych nowych rozwiązaniach i warto się temu przyglądać. Natomiast jeśli masz prawdopodobnie komercyjne rozwiązanie i będziesz kiedyś je aktualizował to zapewne taka funkcjonalność się będzie pojawiała z czasem bez dodatkowych wymagań hardware-owych lub jakiś innych wymagań na implementację tego protokołu. Więc będzie to jedna z dodatkowych opcji, które możemy wykorzystać.

Na dzisiaj to tyle, dziękuję Ci za uwagę. Mam nadzieję, że było ciekawie. Jeśli masz jakieś pytania, to pisz w komentarzu. Jeśli nie to słyszymy się już za tydzień 🙂 Do zobaczenia!