Co naprawdę chroni hasło do prywatnego klucza VPN

Monit, który pojawia się przy starcie klienta VPN, łatwo odczytać błędnie. To nie jest hasło konta VPN, nie jest to hasło tunelu, a jego wpisanie nie dowodzi, że połączenie jest bezpieczne. Odblokowuje jedną zapisaną reprezentację klucza prywatnego, aby klient mógł odczytać materiał klucza i użyć go do uwierzytelnienia. Wszystko, co dzieje się później, to inne pytanie.

W praktyce odpowiedź zawodzi na krawędziach: ludzie zakładają, że hasło chroni działający tunel albo że jego zmiana unieważnia kopię klucza, która już wyciekła. Oba założenia są błędne i oba zawodzą w sposób, który pozostawia dane uwierzytelniające odsłonięte, gdy operator uważa, że sprawa jest załatwiona.

Jeden dialog, kilka różnych sekretów

Hasło klucza prywatnego odszyfrowuje plik. Hasło konta uwierzytelnia cię w usłudze. Hasło importu PKCS#12 odszyfrowuje pakiet zawierający klucz i jego certyfikat i może nie być tym samym ciągiem co hasło samego klucza. Te monity mogą wyglądać niemal identycznie, a zgadywanie, który sekret gdzie trafia, jest tym, jak klucze trafiają wklejone w niewłaściwe pole.

Samo szyfrowanie tunelu to czwarta rzecz. Kanał danych używa kluczy sesji wynegocjowanych podczas uzgadniania; hasło klucza prywatnego nie odgrywa żadnej roli w ochronie poszczególnych pakietów. Jeśli ktoś może odczytać plik klucza, może próbować odgadnąć hasło offline, ale jeśli może czytać pakiety, hasło jest nieistotne.

Co obejmuje szyfrowanie na dysku

Zaszyfrowany klucz PEM występuje w dwóch postaciach, a nagłówek mówi, którą masz. Nowoczesna forma PKCS#8 zaczyna się od -----BEGIN ENCRYPTED PRIVATE KEY-----; starsza forma PEM, wciąż powszechna w starszych konfiguracjach OpenVPN, zaczyna się od -----BEGIN RSA PRIVATE KEY----- i zawiera Proc-Type: 4,ENCRYPTED oraz wiersz DEK-Info tuż pod nim. Plik przechowuje klucz prywatny zaszyfrowany kluczem wyprowadzonym z twojego hasła, zwykle przez KDF oparty na haśle z podaną liczbą iteracji lub współczynnikiem pracy. Dokumentacja OpenSSL pkey omawia formaty i opcje hasła stosowane podczas odczytu.

Wynikają z tego dwie konsekwencje. Słabe hasło można atakować offline w tempie, na które pozwala KDF, więc uprawnienia pliku i dostęp do kopii zapasowych nadal mają znaczenie, nawet gdy plik jest zaszyfrowany. A atakujący, który zdobędzie tylko plik bez hasła, musi zgadywać; ten, kto zdobędzie plik i hasło, ma klucz, dokładnie tak, jakby nigdy nie był zaszyfrowany.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 pokazuje nagłówek, a w starszym pliku wiersze Proc-Type i DEK-Info dowodzące szyfrowania; jeden wiersz sam nie jest dowodem w żadną stronę. Wiersz pkey pyta o hasło i wypisuje tylko połowę publiczną, co dowodzi, że plik i hasło działają bez ujawniania klucza prywatnego. Nie używaj -text do tego sprawdzenia: wypisuje on składniki prywatne, privateExponent, prime1, prime2 i resztę, a tego wyniku nigdy nie wolno nigdzie wklejać, ani do zgłoszenia, ani do czatu, ani do logu. Polecenie PKCS#12 mówi też, czy pakiet ma osobne hasło MAC lub szyfrowania, co warto wiedzieć, zanim przekażesz go współpracownikowi.

Co przestaje chronić po załadowaniu klucza

Odblokowanie to jednorazowe zdarzenie dla tego procesu. Klient prosi KDF o klucz, odszyfrowuje plik i trzyma klucz prywatny w pamięci tak długo, jak go potrzebuje. Od tego momentu hasło nie chroni niczego w działającej sesji: ani pamięci procesu, ani zrzutu jądra, ani sesji debugowania podłączonej do klienta, ani kopii zapasowej maszyny wykonanej podczas używania klucza.

To ta sama granica co klucz SSH z hasłem albo odblokowany sejf menedżera haseł. Podnosi koszt kradzieży pliku w spoczynku i nic nie robi przeciwko złośliwemu oprogramowaniu działającemu jako twój użytkownik, autoryzowanej aplikacji proszącej klienta o podpisanie albo administratorowi, który może czytać pamięć. Traktuj to jako jedną warstwę, a nie mechanizm, który czyni klucz bezpiecznym do porzucenia.

Dlaczego monit ciągle wraca

Klient, który pyta ponownie przy każdym ponownym połączeniu, niekoniecznie jest zepsuty. Niektóre klienty buforują hasło na czas sesji, inne zapisują je w pęku kluczy systemu, a jeszcze inne można skierować do pomocnika, który je dostarcza, więc zachowanie zależy od klienta i jego konfiguracji, a nie od pliku klucza.

Jeśli powtarzający się monit jest prawdziwym problemem, sprawdź opcje buforowania i uwierzytelniania klienta, zanim usuniesz szyfrowanie z klucza. Usunięcie hasła zamienia chroniony plik w klucz jawnym tekstem, a ponowne połączenie staje się ciche kosztem jedynej kontroli w spoczynku, jaką miałeś. Lepsza odpowiedź to zwykle obsługiwany magazyn danych uwierzytelniających z tymi samymi uprawnieniami pliku, których i tak byś używał.

Utrata i ujawnienie to nie ta sama naprawa

Utraconego hasła nie można odzyskać z certyfikatu. Certyfikat to materiał publiczny wiążący nazwę z kluczem; nie zawiera drogi powrotnej do klucza prywatnego ani żadnej wskazówki o haśle. Praktyczne opcje to autoryzowana kopia zapasowa klucza albo nowa tożsamość wydana w normalnym procesie operatora. Każdy, kto oferuje 'odzyskanie' hasła, oferuje jego odgadnięcie.

Ujawnienie wymaga innej reakcji. Ponowne zaszyfrowanie tego samego klucza nowym hasłem pozostawia materiał klucza bez zmian, więc kopia odblokowana już gdzie indziej nadal działa. Naprawą jest unieważnienie lub wymiana danych uwierzytelniających: wydaj nowy klucz i certyfikat, rozdystrybuuj je i wycofaj stary u drugiej strony. Dopóki to nie nastąpi, zmiana hasła pliku jest pracą domową, a nie powstrzymaniem. Trzymaj stary plik poza kopiami zapasowymi dopiero po potwierdzeniu, że nowa tożsamość działa, i zapisz, który numer seryjny lub odcisk palca ją zastąpił.