Błąd słabego szyfru vpnc: polityka bramy czy naprawa pulpitu?
Flaga zgodności DES to wyjątek bezpieczeństwa, a nie naprawa pulpitu. Porównaj ograniczoną zmianę profilu z wymianą spakowanego pliku binarnego vpnc.
Dwie naprawy wyglądają równie szybko, gdy stare połączenie vpnc nie chce się podnieść: przekazać starą flagę słabego szyfru albo wstawić skrypt opakowujący, który doda ją za ciebie. Nie są równoważne, bo jedna zmienia politykę jednego profilu, a druga zachowanie każdego programu, który wywołuje tę ścieżkę. Pierwsze pytanie brzmi, czy brama wciąż oferuje słabą propozycję, a drugie – kto może ją zaakceptować. Wszystko inne wynika z tych dwóch odpowiedzi.
Dwie naprawy o bardzo różnym zasięgu
Zmiana na poziomie profilu dotyka jednego połączenia, jednego właściciela i jednej daty wygaśnięcia. Wymiana zainstalowanego pliku binarnego dotyka każdego frontendu na maszynie, w tym apletu pulpitu, którego kolega używa do zupełnie innego profilu bramy. Opakowanie ukrywa też zmianę przed każdym, kto pół roku później będzie debugował host.
Weryfikacja pakietu jest pierwszą ofiarą: plik w /usr/sbin/vpnc, który nie pasuje już do swojego pakietu, zamienia rutynową aktualizację bezpieczeństwa w śledztwo. Aktualizacje albo po cichu nadpisują opakowanie, albo odmawiają zastosowania, zależnie od tego, jak menedżer pakietów traktuje zmodyfikowane pliki. Żaden z tych wyników nie pojawia się w logu połączenia, dlatego podejście z opakowaniem pozostaje atrakcyjne aż do pierwszego incydentu. Jedna linia w profilu jest znacznie łatwiejsza do znalezienia i usunięcia niż plik binarny, którego wymiany nikt nie pamięta.
Co naprawdę robi przestarzały przełącznik
Podręcznik vpnc oznacza opcję pojedynczego DES jako przestarzałą na rzecz ustawienia słabego szyfrowania i dokumentuje osobną opcję, która w ogóle nie pozwala na szyfrowanie ruchu danych. To różne ustępstwa o różnych konsekwencjach. Żadne z nich nie zmusza nowoczesnej bramy do negocjowania czegoś, czego już nie oferuje.
Przeczytaj fazę awarii, zanim wybierzesz naprawę. Odrzucona propozycja i odrzucone hasło dają podobne komunikaty frontendu, ale zupełnie różne dowody.
Gdzie należy ograniczony wyjątek
Jeśli organizacja świadomie akceptuje starego peera przez ograniczony czas, wyjątek należy do profilu tego peera, z właścicielem, datą przeglądu i ścieżką migracji do obsługiwanego protokołu. Trzymanie go poza globalną ścieżką jest całym sensem nazywania go ograniczonym.
Poproś właściciela bramy o potwierdzenie, jakie algorytmy peer jeszcze oferuje i co go zastępuje. Flaga klienta nie naprawi propozycji, której serwer już nie wysyła, a migracja serwera, której nikt nie zaplanował, przeżyje obejście. Umieść datę przeglądu w tym samym zgłoszeniu co wyjątek, aby ustępstwo wygasło, zamiast stać się trwałe.
Sprawdź negocjację, nie tylko zieloną ikonę
Zbieraj dowody identyfikujące fazę, a nie nastrój dialogu. Poniższe polecenia są tylko do odczytu, a pierwsze dwa pokazują, jaka konfiguracja i wersja są naprawdę w grze.
vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf
Trzecie polecenie raportuje pliki, które nie pasują już do pakietu, i tak zapomniane opakowanie samo się ujawnia. Czwarte pokazuje ustępstwa, które niesie profil, aby wyjątek nie mógł po cichu rozprzestrzenić się na drugi profil przez skopiowany plik. Uruchom oba przed i po zmianie, a wynik zachowaj przy profilu połączenia, a nie w oknie czatu.
Trzymaj dane wyjściowe debugowania poza zgłoszeniami, dopóki ktoś ich nie przeczyta, bo podręcznik ostrzega, że najwyższy poziom debugowania zrzuca dane uwierzytelniania, w tym hasła. Kryterium akceptacji to autoryzowane, obsługiwane porozumienie między klientem a bramą, a nie pozycja menu, która wreszcie zmienia się na zielono. Jeśli peer oferuje tylko zepsuty algorytm, uczciwym wynikiem jest wyjątek z datą końca albo protokół zastępczy, a ta decyzja należy do właściciela bramy. Zapisanie decyzji to różnica między zarządzanym wyjątkiem a przypadkową zmianą polityki.