VPN TLS kontra IPsec: pięć pól, które warto przejrzeć

Szeregowanie VPN TLS i VPN IPsec według rodziny protokołów odpowiada na pytanie, którego nikt nie zadał, i zwykle cytuje konstrukcję, którą obie rodziny porzuciły lata temu. To, co recenzent może faktycznie ocenić, to wynegocjowana ochrona, tożsamość peera, model klienta i eksponowana usługa. Te cztery rzeczy są widoczne we wdrożeniu i żadna z nich nie wynika z etykiety produktu. Poproś o pięć pól, a rozmowa staje się konkretna.

Pięć pól, a etykieta nie jest jednym z nich

Pierwsze pole to obsługiwane wydanie oprogramowania, ponieważ opis protokołu bez wersji jest broszurą. Drugie to wynegocjowana wersja protokołu, która decyduje, jakie konstrukcje są w ogóle dostępne. Trzecie to zestaw ochronny, czwarte to metoda uwierzytelniania zarówno peera, jak i użytkownika, a piąte to zakres dostępu przyznawany przez produkt po dopuszczeniu.

Etykieta VPN SSL obejmuje co najmniej trzy różne produkty: pełnego klienta sieciowego, proxy aplikacji i starszy portal oparty na przeglądarce. Eksponują różne usługi i zawodzą inaczej, więc etykieta nie może zastąpić pola zakresu.

Co naprawdę zmienia szyfrowanie uwierzytelnione

TLS 1.3 wymaga szyfrowania uwierzytelnionego, co usuwa z protokołu starszą konstrukcję MAC-then-encrypt, zamiast pozostawiać ją jako opcję. IPsec ESP ma zestawy szyfrowania uwierzytelnionego równie długo, z AES-GCM zdefiniowanym we własnym RFC. W obu rodzinach gwarancja pochodzi z wynegocjowanego zestawu, a nie z nazwy rodziny, dlatego lista pól zaczyna się od wersji. Recenzent, który nie potrafi nazwać zestawu, nie ma czego oceniać.

Dlatego porównanie historyczne jest mylące. Wdrożenie przypięte do starej wersji TLS z zestawem CBC i takie, które uruchamia TLS 1.3 z zestawem AEAD, nie mają tej samej postawy bezpieczeństwa, choć oba są VPN TLS. Ten sam podział istnieje po stronie IPsec między nowoczesnym zestawem ESP a starszą kombinacją.

Czytaj wynegocjowane wartości, a nie konfigurację, którą zamierzałeś zastosować. Poniższe polecenia pokazują, na czym faktycznie zgodziły się działający punkt końcowy i działający tunel.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Jeśli punkt końcowy nie chce negocjować TLS 1.3, to jest ustalenie, a nie preferencja. Jeśli tunel wymienia zestaw, którego się nie spodziewałeś, konfiguracją, która się liczy, jest ta wybrana przez peerów, a nie ta z szablonu.

Tożsamość peera to osobne pytanie

Szyfrowanie bez zweryfikowanego peera chroni ruch przed obserwatorami i oddaje go temu, kto odpowiedział na połączenie. Uwierzytelnianie peera pyta, jaka tożsamość jest oczekiwana, jaki materiał zaufania ją potwierdza i jak klient zachowuje się, gdy odpowiedź się nie zgadza. Łańcuch certyfikatów, przypięty klucz i wcześniej współdzielony sekret to trzy różne odpowiedzi o trzech różnych kosztach operacyjnych.

Następnie zadaj te same pytania o użytkownika lub urządzenie. Brama, która uwierzytelnia maszynę i dopuszcza dowolnego użytkownika, lub odwrotnie, ma konkretną postawę, którą należy opisać, a nie zakładać. Uprawnienia do zasobów stosowane po dopuszczeniu są częścią tego samego pola, ponieważ uwierzytelnianie nie jest autoryzacją.

Zachowanie kontroli nazwy hosta i certyfikatu znaczy więcej niż znajomość okna logowania. Klient skonfigurowany tak, by ignorować weryfikację, usunął jedyny krok, który odróżnia twoją bramę od przekonującej imitacji.

Granica, którą eksponuje produkt

Portal bezkliencki pośredniczy w wybranych operacjach aplikacji przez bramę, więc użytkownik dociera do interfejsu, a nie do sieci. Klient pełnego tunelu przenosi to, co wybierają jego trasy i polityka filtrowania, czyli znacznie większą powierzchnię. Porównywanie obu pod względem siły protokołu pomija różnicę w tym, do czego atakujący może dotrzeć przez nie. Jeden eksponuje interfejs aplikacji, drugi sieć z trasowaniem, i oba wymagają innych przeglądów.

Zapytaj, jaka usługa jest eksponowana, jakie operacje są autoryzowane i na czym nasłuchuje sama brama. Interfejs administracyjny osiągalny z tego samego adresu co portal użytkownika to ustalenie wdrożeniowe i żaden wybór protokołu tego nie zrekompensuje.

Zakres na aplikację jeszcze zawęża powierzchnię i zmienia też zachowanie przy awarii, gdy tunel padnie. Projekt zakładający zasięg pełnego tunelu psuje się w sposób, którego projekt per aplikacja nie zna, a obciążenie wsparcia idzie za tym.

Zdecyduj wynik awarii i cykl życia

To, co się dzieje, gdy uwierzytelnianie lub ochrona są niedostępne, jest decyzją polityki, która należy do przeglądu. Zablokowany wynik i nieogłoszony bezpośredni powrót mają różne konsekwencje, a różnica jest niewidoczna na liście funkcji. Podaj zamierzone zachowanie obok zasobu, który chroni.

Uwzględnij cykl życia poprawek i wsparcia bramy, włączone funkcje zewnętrzne i ścieżkę aktualizacji klientów. Prawidłowy wybór protokołu nie czyni bezpieczną źle wdrożonej usługi, a większość incydentów żyje w tej luce, a nie w zestawie.

Zapisz pięć pól, politykę awarii i właściciela cyklu życia na jednej stronie. Ta strona jest przeglądem; porównanie rodzin protokołów jest opinią.