Dlaczego AES-256 nie opisuje zestawu szyfrowania VPN
Zestaw pełni cztery role: szyfrowanie masowe, integralność, ustalanie kluczy i uwierzytelnianie drugiej strony. Nazwa szyfru obejmuje tylko jedną z nich, na jednej warstwie.
Zapytaj, jakiego szyfrowania używa VPN, a odpowiedź zwykle przychodzi jako jedno słowo: AES-256, albo ChaCha20, albo może WireGuard. Ta odpowiedź nazywa jeden składnik jednej warstwy, podczas gdy to, co naprawdę chroni połączenie, to zbiór algorytmów pełniących cztery różne role. Mylenie składnika z układem jest najczęstszym błędem w tych rozmowach i tworzy porównania, których nie da się rozstrzygnąć.
Cztery zadania w jednym połączeniu
Szyfrowanie masowe zamienia tekst jawny na szyfrogram dla kanału danych, a jego klucz jest wyprowadzany, a nie przesyłany. Ochrona integralności wykrywa zmianę, co jest osobnym zadaniem, nawet gdy jedna konstrukcja robi jedno i drugie. Ustalanie kluczy wytwarza wspólny materiał ruchu, a uwierzytelnianie drugiej strony decyduje, kto jest po drugiej stronie. Jeśli brakuje któregokolwiek, połączenie nie jest bezpieczne, niezależnie od siły pozostałej części.
Niektóre projekty łączą dwie role w jedną. AES-GCM i ChaCha20-Poly1305 to konstrukcje szyfrowania uwierzytelnionego, więc poufność i integralność przychodzą razem; AES-CBC nie, i wymaga osobnego kodu uwierzytelniania wiadomości z własnym kluczem. Dlatego czytanie propozycji jako worka niezależnych liczb źle czyta te, które zaprojektowano jako pary.
Role leżą też na różnych warstwach, dlatego to samo słowo może znaczyć co innego w dwóch produktach. Szyfr blokowy w ESP i szyfr blokowy w TLS to ten sam prymityw w różnych negocjacjach z różnymi wymaganiami. Dlatego cytowanie prymitywu bez jego trybu i warstwy może być gorsze niż niecytowanie niczego.
Dlaczego nazwa szyfru mówi prawie nic
Weźmy na chwilę poważnie wyrażenie AES-256: wskazuje ono szyfr blokowy i długość klucza. Nie mówi nic o trybie pracy, o tym, czy zapewniona jest integralność, jak ustalono klucze ani jak uwierzytelniono drugą stronę. Dwa produkty mogą oba reklamować AES-256 i różnić się we wszystkim innym, w tym jeden łączący go z trybem nieuwierzytelnionym, a drugi używający trybu AEAD z nowoczesną wymianą kluczy.
TLS 1.3 wprowadził ten rozdział do standardu, co jest użyteczną poprawką dla każdego, kto uczył się starszego słownictwa. Jego zestawy szyfrów nazywają tylko AEAD i skrót, podczas gdy grupy wymiany kluczy i algorytmy podpisu są negocjowane jako osobne parametry. Dlatego nazwy zestawu TLS 1.3 nie można porównywać z nazwą zestawu TLS 1.2 na równych zasadach, choć obie pojawiają się w tym samym polu pliku konfiguracyjnego. Audytor, który porównuje oba ciągi bezpośrednio, wyciąga wniosek, którego protokół nie popiera. Przeczytaj także wynegocjowaną grupę i parametry podpisu, inaczej porównanie jest niepełne.
WireGuard wybiera przeciwną drogę i usuwa negocjacje niemal całkowicie: protokół narzuca stały zestaw algorytmów, więc dwie implementacje albo współpracują, albo nie. To uzasadniony wybór projektowy, a zarazem oznacza, że pytanie, jaki zestaw negocjuje WireGuard, nie ma odpowiedzi godnej porównania. Jeśli go audytujesz, przeczytaj specyfikację raz, a potem audytuj obsługę kluczy wokół niej, a nie negocjacje.
Warstwa decyduje o słownictwie
Wdrożenie IPsec negocjuje dwa razy: propozycję IKE dla kanału sterującego i transformację ESP dla danych, i te dwa mogą legalnie się różnić. Czytanie pierwszej i zakładanie, że opisuje drugą, jest częstym źródłem zamieszania podczas audytu, ponieważ plik konfiguracyjny wymienia obie, a interesująca jest druga.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Nazwa dostępna w jednej bibliotece nie jest automatycznie zaimplementowana dla innej ścieżki danych. Dlatego twierdzenie, że nasz produkt obsługuje AES-256, jest słabsze, niż brzmi, i dlatego problem interoperacyjności zwykle rozwiązuje się, znajdując utrzymywany przekrój, a nie włączając każdy stary algorytm po obu stronach.
Specyfikacja TLS 1.3 to najjaśniejszy opublikowany przykład tego rozdziału, ponieważ definiuje zestaw jako parę i przenosi resztę do własnych negocjacji. Gdy ten kształt jest znany, propozycja IPsec i jedyny stały zestaw WireGuard czytają się jako warianty tej samej idei.
Przeczytaj wynegocjowany wynik, potem przestań
Skonfigurowana propozycja nie jest dowodem na to, co wybrały dwie strony. Żywa sesja niesie odpowiedź, a każda popularna implementacja może ją zaraportować bez przechwytywania pakietów.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showW wyniku czytaj wybrane algorytmy, a nie oferowaną listę. Jeśli odpowiedź jest słabsza, niż zakładała polityka, poprawka należy do konfiguracji propozycji po jednej ze stron, a niezgodność w nowoczesnych implementacjach objawia się zwykle jako nieudane negocjacje, a nie ciche obniżenie.
Potem pamiętaj, czego zestaw nie obejmuje. Trasy, uprawnienia aplikacji, rejestrowanie i przechowywanie to osobne decyzje z własnym przeglądem, a zgodny układ kryptograficzny nic o nich nie mówi. Dyskusja o szyfrze jest warta zachodu, ale odpowiada na węższe pytanie niż to, które większość ludzi naprawdę zadaje.
Trzymaj słownictwo precyzyjne, a argument się skraca. Zestaw to zbiór ról na warstwie, szyfr to jeden składnik, a wynegocjowany wynik to jedyna rzecz, która opisuje połączenie, które naprawdę masz. Wszystko inne w porównaniu jest ozdobą.