Sprawdzanie certyfikatu VPN bez ujawniania klucza

Odczytanie publicznych pól certyfikatu nigdy nie wymaga pokazywania pasującego do niego klucza prywatnego, a narzędzia do tego są częścią każdego systemu, który kończy połączenie VPN. Ryzyko pojawia się o krok wcześniej: plik, który otrzymałeś, może wcale nie być certyfikatem. Certyfikat PEM, plik binarny DER, pakiet PKCS#12 i profil OpenVPN mogą trafić do ciebie pod tą samą nazwą i zawierać zupełnie inny materiał, więc najpierw ustal, z jakim pojemnikiem masz do czynienia, a potem wybierz polecenie.

Trzy fakty decydują o tym, które polecenie jest bezpieczne: co zawiera plik, co chcesz z niego odczytać i kto zobaczy dane wyjściowe. Pomyłka w którymkolwiek z nich sprawia, że samo sprawdzanie staje się incydentem.

Który z trzech plików otrzymałeś

Certyfikat PEM to tekst z widocznymi znacznikami BEGIN i END, plik DER to dane binarne wymagające flagi formatu wejściowego, a pakiet to pojemnik, który może zawierać klucz obok certyfikatu. file server.crt w sekundę oddziela tekst od danych binarnych, a jedno spojrzenie na pierwszą linię odróżnia sam certyfikat od profilu, który go zawiera. Zgadywanie w tym miejscu jest tym, co zamienia sprawdzanie w incydent.

Jeśli plik jest profilem, a nie certyfikatem, traktuj go jak dane uwierzytelniające, dopóki nie udowodnisz, że jest inaczej. Takie założenie nic nie kosztuje i zapobiega najczęstszemu błędowi w całym tym zadaniu.

Odczyt publicznych pól certyfikatu PEM

W przypadku certyfikatu, który masz prawo sprawdzić, podpolecenie x509 z -noout wypisuje wybrane pola i nic więcej. Pominięcie treści ogranicza dane wyjściowe do metadanych, dzięki czemu można je bezpiecznie wkleić do zgłoszenia. Wybieraki poniżej są publiczne, a dokumentacja openssl x509 wymienia pozostałe.

openssl x509 -in server.crt -noout -subject -issuer -dates -fingerprint -sha256

Na wygenerowanym lokalnie certyfikacie testowym to polecenie wypisuje wiersz subject i issuer, parę notBefore i notAfter oraz jeden odcisk palca SHA-256. Te pola identyfikują obiekt; nie ustanawiają ważnej ścieżki zaufania, co jest osobnym zadaniem weryfikacyjnym z własnym poleceniem i własną odpowiedzią. Plik łańcucha może też wypisać tylko pierwszy certyfikat, chyba że sam przejdziesz przez cały plik. Porównanie dwóch plików w ten sposób kosztuje jedno polecenie i rozstrzyga, który z nich druga strona faktycznie prezentuje.

Pakiety, które zawierają klucz obok certyfikatu

Plik .p12 lub .pfx może zawierać klucz prywatny, a polecenie analizujące wypisze go, jeśli nie pominiesz tej części danych wyjściowych. Z -nokeys to samo polecenie nadal raportuje strukturę pojemnika, w tym osłonięty worek klucza, bez emitowania jakiegokolwiek materiału klucza; usuń tę flagę, a blok klucza pojawi się w terminalu i w historii powłoki.

openssl pkcs12 -in bundle.p12 -nokeys -info -passin env:P12PASS

Profil OpenVPN zawiera ten sam materiał jako tekst, więc granica jest widoczna, jeśli wiesz, gdzie patrzeć. Materiał publiczny leży między BEGIN CERTIFICATE a END CERTIFICATE, natomiast wszystko między BEGIN PRIVATE KEY a pasującym wierszem END to klucz, który nie może opuścić hosta. Skopiowanie profilu w całości publikuje jedno i drugie.

Skąd wziąć wartość referencyjną

Odcisk palca odczytany z połączenia, które próbujesz zweryfikować, niczego nie dowodzi, ponieważ dostarczyła go strona, której nie ufasz. To nie jest argument przeciw odciskom palca; to argument o pochodzeniu. Porównaj wartość z tą uzyskaną kanałem, do którego druga strona nie może pisać, na przykład z certyfikatem opublikowanym w wewnętrznym repozytorium albo z hashem wypisanym w podpisanym zapisie zmiany.

Tam, gdzie walidację wykonuje magazyn zaufania, pozwól mu to zrobić i odczytaj wygenerowany błąd, zamiast zastępować go własnym porównaniem. Znaczenie ma to, kto dostarczył wartość referencyjną, a nie to, której funkcji skrótu użyto.

Udostępnianie wyniku i co robić po wpadce

Wyślij dokładny błąd walidacji, odpowiednie daty i tylko te dane identyfikacyjne, których odbiorca potrzebuje. Wewnętrzne nazwy hostów i identyfikatory kont pozostają wrażliwe, nawet gdy nie ma przy nich klucza, a publiczna usługa wklejania to złe miejsce dla czegokolwiek z tego. Wklejaj do zgłoszenia, a nie do wspólnego bufora roboczego.

Jeśli materiał klucza jednak pojawił się na ekranie lub w pliku, traktuj go jako ujawniony i wymień go, zamiast mieć nadzieję, że nikt nie patrzył. Następnie zapisz, który plik sprawdzono, jakiego polecenia użyto i gdzie trafiły dane wyjściowe, ponieważ ten zapis zamienia strach w procedurę. Wymiana klucza jest tania w porównaniu z kosztem założenia, że nikt nie zrobił zrzutu ekranu, a ten sam zapis mówi następnemu inżynierowi, których plików w ogóle dotknięto. Zrób jedno i drugie, zanim zgłoszenie zostanie zamknięte.