Zaszyfrowany klucz prywatny i klucz niezaszyfrowany zawierają ten sam materiał klucza. Konwersja nie tworzy nowej tożsamości, nie resetuje konta VPN i nie unieważnia starego pliku. Zapisuje drugą kopię, a ta kopia niesie inne ryzyko w spoczynku.

To, czy wymiana się opłaca, zależy od tego, gdzie będzie leżał plik i kto może go odczytać.

Co konwersja naprawdę zmienia

Przed konwersją klucz jest chroniony hasłem podawanym przez operatora. Po konwersji chronią go uprawnienia systemu plików i wszelka kontrola dostępu wokół pliku. Kryptografia się nie zmieniła; zmieniła się liczba rzeczy między atakującym a kluczem. To całe porównanie.

Tabela czyni różnicę konkretną.

FormWhat protects itHow it fails
Encrypted keyA passphrase plus file accessWeak passphrase, or an offline attack on the file
Unencrypted keyFile permissions and host security onlyAny reader copies it silently

Żadna z form nie jest automatycznie bezpieczniejsza. Zawodzą na różne sposoby, a tylko jeden z tych sposobów zostawia wpis w logu.

Kiedy lepiej zachować hasło

Jeśli obsługiwany klient może zapytać o hasło lub pobrać je z zatwierdzonego magazynu sekretów, konwersja niczego nie daje. Zachowujesz jedną kopię, jedną granicę ochrony i o jeden plik mniej do śledzenia. Większość klientów VPN akceptujących klucze PEM potrafi to zrobić.

Konwersja to także zły ruch, gdy zespół dzieli klucz. Niezaszyfrowany plik na współdzielonym hoście staje się poświadczeniem, które każdy z dostępem do powłoki może skopiować.

Kiedy niezaszyfrowana kopia jest uzasadniona

Niektóre usługi nie mogą zapytać, niektóre kontenery montują sekrety tylko do odczytu, a niektóre urządzenia czytają plik klucza przy starcie bez ścieżki interaktywnej. W takich przypadkach niezaszyfrowany klucz w odpowiednio ograniczonym katalogu może być obsługiwanym projektem. Uzasadnieniem jest środowisko, nie wygoda.

Jeśli nie możesz powiedzieć, kto może odczytać plik i dlaczego, odpowiedź brzmi nie.

Polecenie i jego ostre krawędzie

Dla klucza opartego na pliku obsługiwanego przez OpenSSL 3.5, dokumentacja pkey opisuje usuwanie hasła i interaktywne pytanie, gdy dane wejściowe są zaszyfrowane, a źródło hasła nie zostało podane. Minimalna forma jest krótka i łatwo ją uruchomić nieostrożnie.

umask 077
openssl pkey -in protected-key.pem -out new-private-key.pem

Trzy ostre krawędzie. Wejście/wyjście pliku wyjściowego nie jest atomowe, więc istniejąca ścieżka wyjściowa może zostać obcięta w połowie zapisu. Nie używaj ścieżki wejściowej jako wyjścia i nie eksperymentuj na jedynej chronionej kopii. Wpisz hasło w pytaniu, a nie w wierszu poleceń, gdzie trafia do historii powłoki.

Sprawdź wynik, zanim zmienisz jakąkolwiek konfigurację VPN: openssl pkey -in new-private-key.pem -pubout powinno wypisać ten sam klucz publiczny, który miałeś wcześniej.

Czego konwersja nie robi

Nie unieważnia zaszyfrowanej kopii, która nadal istnieje tam, gdzie ją zostawiłeś. Nie zmienia hasła konta VPN ani certyfikatu. I nie naprawia ujawnienia, które już nastąpiło. Jeśli klucz wyciekł, rozwiązaniem jest wymiana i unieważnienie po stronie serwera, a nie lokalna zmiana formatu.

Usuń plik pośredni świadomie i potwierdź, że usuwana ścieżka to ta, którą utworzyłeś.

Powiązane artykuły