0x czy 0s? Jak czytać format PSK w ipsec.secrets

Jeden klient uwierzytelnia się współdzielonym kluczem, a drugi go odrzuca, choć wklejone znaki wyglądają po obu stronach tak samo. To prawdopodobnie te same znaki; różnica polega na tym, którą regułę dekodowania stosuje do nich plik. Ciąg w cudzysłowie jest brany dosłownie, token zaczynający się od 0x jest czytany jako szesnastkowy, a token zaczynający się od 0s jest czytany jako Base64. Tylko jeden z tych trzech zapisów znaczy to, co zamierzałeś, więc poprawka jest zwykle konwersją, a nie lepszym hasłem.

Objaw wskazuje na kodowanie, nie na szyfry

Gdy oba końce trzymają różne bajty, negocjacja nadal się udaje, a dowód zawodzi po niej. Log zgłasza wtedy błąd integralności lub HMAC, a nie niezgodność algorytmu, ponieważ propozycja została wybrana, a krok uwierzytelniania nie pasował. Ten wiersz nigdy nie wspomina kształtu sekretu.

Etap jest wskazówką. Błąd pojawiający się po wybranej propozycji oznacza, że obie strony zgodziły się na wszystko poza materiałem klucza, podczas gdy „nie wybrano propozycji” należy do polityki lub zestawów szyfrów. Sprawdzenie integralności, które zawodzi, gdy hasło wygląda poprawnie, jest widoczną twarzą niezgodności kodowania.

Jeden sekret, trzy sposoby, w jakie plik może go odczytać

Dla wartości czterech bajtów key1 szesnastkowy i Base64 to dwa przekodowania tych samych bajtów, a tylko wiodące znaki mówią parserowi, który z nich trzyma. Poświadczenia swanctl podlegają tej samej konwencji, więc wartość przeniesiona między dwoma interfejsami zachowuje znaczenie tylko wtedy, gdy jej prefiks wędruje razem z nią.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Dwa szczegóły w tym bloku kosztują najwięcej czasu. Cyfry szesnastkowe akceptują oba warianty, więc 0x6b657931 i 0x6B657931 to ta sama wartość, ale nieparzysta liczba znaków jest po cichu czytana błędnie zamiast odrzucona, co przesuwa każdy bajt po cięciu. Dopełnienie Base64 jest częścią wartości, więc ciąg wklejony bez końcowych znaków = dekoduje się na inne bajty zamiast głośno zawodzić.

Profil, który raz zdekodował wartość, już ją przekonwertował, więc ponowne dekodowanie daje inne bajty i błąd uwierzytelniania, który czyta się jak złe hasło. Cudzysłowy są bezpiecznym kierunkiem dla wszystkiego niejednoznacznego, ponieważ zawartość jest dosłowna nawet wtedy, gdy zaczyna się od znacznika kodowania.

Skąd pochodzi tekst Base64

Eksporty profili i portale dostawców często przekazują klucz już zakodowany, zwykle w polu danych, które nigdy nie było przeznaczone do ręcznego wpisywania. Albo rozpakuj tę wartość i zapisz zdekodowany tekst w cudzysłowie, albo zostaw ją zakodowaną ze znacznikiem z przodu. Zrobienie połowy jednego i połowy drugiego jest tym, co psuje. Obie drogi działają tylko wtedy, gdy cała wartość przetrwa kopiowanie.

Oba kierunki to po jednym poleceniu i warto zachować je w tickecie jako dokładną operację, która wytworzyła zapisaną wartość. Uruchom je w tej kolejności:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Wklejenie zakodowanego tekstu tak, jakby był zwykły, jest kosztownym błędem. Plik haszuje znaki dokładnie tak, jak zostały zapisane, wyprowadzony klucz wychodzi około jedną trzecią dłuższy niż ten obliczony przez partnera, a każda próba zawodzi w ten sam sposób bez ostrzeżenia, ponieważ parser postąpił według podanej mu reguły.

Potwierdź, których bajtów każdy partner faktycznie używa

Najpierw przeczytaj widok demona na połączenie, a potem wynik uwierzytelniania, zamiast zgadywać przyczynę z ciągu błędu. Porównanie zapisanej długości to szybka kontrola zdrowego rozsądku, ponieważ zakodowany tekst jest dłuższy niż reprezentowane przez niego bajty. Następnie potwierdź, który wiersz tożsamości pasował, ponieważ poprawny sekret umieszczony pod złym partnerem zawodzi dokładnie tak jak błędny. Decyduje o tym kolejność wierszy: pierwsze dopasowanie wygrywa, więc szeroki %any wiersz blisko góry po cichu zastępuje konkretny wiersz, który właśnie edytowałeś.

Przeładuj zamiast restartować, gdy plik jest już poprawny. ipsec rereadsecrets odświeża kopię demona IKE, a instalacja swanctl ładuje poświadczenia własnym poleceniem. Restart zrywa każde nawiązane skojarzenie i niszczy porównanie, które próbowałeś przeprowadzić.

Żadne z tych sprawdzeń nie wymaga ujawnienia sekretu. Długość, selektor tożsamości i pozycja wiersza wyjaśniają większość takich błędów, zanim ktokolwiek potrzebuje zrzutu szesnastkowego.

Zmień plik, nie ukrywając wyniku

Ogranicz plik do konta demona i trzymaj żywe sekrety poza ticketami, czatem i zrzutami ekranu, ponieważ wklejony klucz to wyciek, a nie diagnoza. Przeżywa też incydent, który go wytworzył.

Testuj z klienta, którego konfigurację kontrolujesz, potwierdź, że uwierzytelnianie się udaje, a następnie potwierdź, że tunel przenosi ruch. Przeładowanie, które naprawia uścisk dłoni, podczas gdy routing pozostaje zepsuty, to inny problem i staje się widoczne, gdy tylko sekret przestaje się poruszać.