Czy nieudany handshake VPN to naprawdę atak downgrade?

Handshake, który kończy się błędem, wygląda jak atak, dopóki nie spojrzysz na komunikat, i najczęściej jest to arytmetyka: brak wspólnej propozycji, wygasły certyfikat albo pakiet, który nigdy nie dotarł. Atak downgrade jest czymś konkretnym: przeciwnik popycha obie strony ku słabszemu zachowaniu, niż wybrałyby, i zostawia inne dowody. Traktowanie każdej porażki jako złośliwości każe szukać ofiary, której może nie być, a traktowanie prawdziwego downgrade’u jako błędu konfiguracji zostawia słabszy wynik na miejscu. Te dwa błędy kosztują różnie i tylko jeden z nich jest tani do naprawienia.

Co atak downgrade faktycznie zmienia

Celem nie jest złamanie szyfru ani odgadnięcie klucza. Celem jest wpłynięcie na negocjacje tak, aby obie strony zatrzymały się na starszej wersji lub słabszym algorytmie, z którym poradzi sobie atakujący, albo aby jedna strona uwierzyła, że druga obsługuje tylko to.

Zmienia się uzgodnienie, nie uwierzytelnienie. Jeśli atakujący może zmienić ofertę bez wykrycia, strony nadal mogą ukończyć handshake i nadal się uwierzytelniać, ale z parametrami preferowanymi przez atakującego. Dlatego interesujące pytanie brzmi, czy same negocjacje są objęte ochroną integralności.

Dlaczego same negocjacje muszą być uwierzytelnione

TLS 1.3 czyni tę ochronę jawną. Klient, który zaproponował nowszą wersję, potrafi wykryć serwer, który po cichu się cofnął, ponieważ losowa wartość serwera niesie stały wzorzec, gdy negocjuje 1.2 lub niżej, a klient musi przerwać, widząc to. Cały transkrypt jest też objęty komunikatami końcowymi, więc zmiana w dowolnym miejscu negocjacji zawodzi później, zamiast przechodzić po cichu.

Starsze wersje protokołu miały słabsze historie i właśnie dlatego reguły wycofywania mają znaczenie. Punkt końcowy TLS 1.0 w tej samej konfiguracji nie jest atakiem downgrade; to dozwolony wynik, na który sam się zgodziłeś. Różnica polega na tym, czy słabszy wynik pochodzi z chronionej decyzji, czy z niechronionej ścieżki, na którą mógł wpłynąć pośrednik. Gdy ujmiesz to w ten sposób, większość incydentów sprowadza się do pytania o konfigurację.

IKEv2 zachowuje się inaczej, ale opiera się na tej samej idei. Propozycja jest przenoszona w wymianie, która później uwierzytelnia obie strony, więc urządzenie pośredniczące przepisujące algorytmy psuje uwierzytelnienie, zamiast nim kierować. Kanał kontrolny OpenVPN chroni swoje negocjacje za pomocą TLS, a następnie używa tego kanału do uzgodnienia szyfrów kanału danych, i dlatego właśnie wiersz dziennika kanału kontrolnego jest interesujący.

Skonfigurowana zgodność to nie atak

Administrator może świadomie zezwolić na starsze opcje, aby obsłużyć udokumentowanego klienta, a ta decyzja jest widoczna w konfiguracji. Atakujący nie może stworzyć takiej konfiguracji; może jedynie wykorzystać ścieżkę, która pozwala mu wpłynąć na ofertę.

Niebezpieczna naprawa to ta, która usuwa dowód różnicy. Włączenie każdej starszej opcji, wyłączenie weryfikacji certyfikatu lub akceptowanie dowolnego szyfru, aby błąd zniknął, poszerza to, na co punkt końcowy się zgodzi, i usuwa kontrole, które zgłosiłyby słabszy wynik.

Jeśli musisz zachować jedną starą opcję, podaj powód i klienta w komentarzu konfiguracji, a następnie ogranicz opcję do profilu, który jej potrzebuje. Wyjątek zgodności ograniczony do jednego odbiornika jest audytowalny; zastosowany globalnie to tylko słabsza wartość domyślna, której nikt nie pamięta, że ją wybrał.

Przeczytaj awarię, zanim nazwiesz przyczynę

Przed jakąkolwiek zmianą zachowaj dokładny ciąg błędu, wersje klienta i serwera oraz czas. Następnie sklasyfikuj: strony nie zgodziły się co do propozycji, ścieżka pakietów zawiodła, czy jedna strona odrzuciła parametr, który kiedyś akceptowała?

Niezgodność propozycji zwykle wskazuje winne wersje lub algorytmy i zawodzi w tym samym punkcie za każdym razem. Problem z routingiem lub MTU zatrzymuje się lub kończy przekroczeniem czasu i często zmienia się wraz z siecią. Wygasły certyfikat daje błąd weryfikacji, a nie negocjacji.

Nic z tego nie jest dowodem atakującego. Przypisanie złośliwej przyczyny przy pierwszej porażce jest błędem, ponieważ ukrywa deterministyczny błąd, który zawiedzie ponownie jutro.

Potwierdź, co faktycznie wybrano

Po każdej poprawce przeczytaj wynegocjowany wynik, zamiast ufać, że połączenie się podniosło. Połączenie, które się udaje, bo usunięto weryfikację, jest wynikiem, którego chciałeś uniknąć. Dwie poniższe komendy pokazują wybraną wersję i szyfr dla punktu końcowego z TLS z przodu oraz wiersz kanału kontrolnego z dziennika serwera OpenVPN.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Porównaj wynik z konfiguracją, którą zamierzałeś, a nie z tym, co teraz się łączy. Jeśli wybrana wersja jest starsza niż dozwolone minimum, profil lub lista wycofywania to miejsce, w którym trzeba szukać, a odpowiedzią jest naprawienie tej listy, a nie ogłoszenie ataku i odbudowa wszystkiego wokół.