Czy ten opublikowany klucz OpenVPN to CA, klucz partnera czy tls-auth?

Ktoś zgłasza, że klucz VPN jest publiczny, a to zdanie ukrywa trzy zupełnie różne sytuacje. Może to być certyfikat CA, który powinien mieć każdy klient, prywatny klucz tożsamości, który nigdy nie powinien opuścić jednej maszyny, albo wspólny sekret kanału sterującego, który muszą trzymać obie strony. Naprawa, pilność i zasięg szkód różnią się w każdym przypadku, więc pierwszym zadaniem jest klasyfikacja, a nie działanie. Pomyłka w kategorii oznacza, że każdy kolejny krok jest zmarnowanym wysiłkiem.

Zacznij od dyrektywy, nie od nazwy pliku

Przeczytaj aktywną konfigurację i ustal, która dyrektywa wskazuje na dany materiał. Opcje TLS OpenVPN używają ca dla zaufanego materiału certyfikatu, cert dla certyfikatu lokalnego partnera i key dla należącego do niego klucza prywatnego.

Nazwy plików niczego nie dowodzą. Plik o nazwie key.pem może zawierać certyfikat, a blok osadzony w profilu może zawierać dokładnie ten sam obiekt co osobny plik na dysku. Otwórz plik i spójrz na jego nagłówek, zamiast ufać nazwie. Ten jeden test usuwa większość niejasności w zgłoszeniu.

Jeśli profil jest pakietem PKCS#12, rozpakuj go w kontrolowanym miejscu, aby zobaczyć, co naprawdę zawiera. Jeden pakiet może zawierać certyfikat, jego łańcuch i klucz prywatny, co oznacza, że wyciek pakietu jest wyciekiem wszystkich trzech.

Zapisz klasyfikację, zanim ktokolwiek zmieni plik: obiekt, dyrektywa, które strony go mają i kto może go czytać. Od tego zdania zależy reszta odpowiedzi.

Certyfikat CA jest przeznaczony do udostępniania

Publiczny certyfikat CA to materiał zaufania. Klienci potrzebują go do weryfikacji serwera, a jego dystrybucja to normalny przypadek, a nie incydent. Opublikowanie go nie publikuje prywatnego klucza podpisującego CA, a właśnie ten obiekt pozwoliłby atakującemu tworzyć nowe tożsamości.

Warto zapisać tę różnicę wprost w zgłoszeniu, bo oba pojęcia są stale mylone. Pytanie, na które trzeba odpowiedzieć, brzmi, czy ujawniony plik to certyfikat, czy klucz podpisujący, i szybkie spojrzenie w zawartość pliku to rozstrzyga. Certyfikat zawiera klucz publiczny i podpis; klucza podpisującego nie ma w nim w ogóle.

Dystrybucja wciąż wymaga staranności. Klienci powinni otrzymywać certyfikat zatwierdzoną ścieżką dostarczania profili, a nie z serwisu do wklejania, a certyfikat, który dotrze niezaufaną drogą, może zostać podmieniony w tranzycie.

Klucz partnera i sekret tls-auth nie są

Prywatny klucz partnera to materiał tożsamości. Po skopiowaniu serwer nie potrafi już odróżnić zamierzonego urządzenia od kogokolwiek, kto ma kopię, ponieważ wyłączne posiadanie było cechą, którą wykazywano. Dalsza autoryzacja i wymiana to decyzje właściciela VPN, a nie tego, kto znalazł plik.

Sekret tls-auth to trzecia rzecz. Dodaje uwierzytelnianie HMAC wokół pakietów kanału sterującego, aby błędnie uwierzytelnione pakiety były odrzucane przed wymianą TLS, i nie jest ani kluczem prywatnym partnera, ani kluczem szyfrującym dane aplikacji.

Jeśli ten wspólny sekret jest publiczny, bariera, którą dawał, zniknęła dla wszystkich, którzy go mają. Nie wynika z tego, że każdy posiadacz przechodzi kontrole certyfikatu i użytkownika za nią, dlatego klasyfikacja jest ważniejsza niż poziom alarmu. Powiedz, która bariera upadła, i powiedz, które zostały.

Napraw rolę, która wyciekła, a nie sąsiednią

Wspólnego sekretu nie da się ponownie uczynić prywatnym przez zmianę nazwy pliku lub ukrycie linku do pobrania. Wymiana oznacza wygenerowanie nowej wartości i rozdzielenie jej do każdego partnera w skoordynowanej zmianie, a wymiana tylko jednej strony psuje ustalenie wszystkim, którzy nadal mają starą wartość.

Jeśli tożsamość partnera została ujawniona, użyj procesu unieważnienia i ponownej rejestracji operatora dla tej tożsamości. Zmiana hasła niepowiązanego konta nie unieważnia skopiowanego certyfikatu, podobnie jak podmiana pliku tls-auth.

Zanim na czymkolwiek z tego się oprzesz, potwierdź, co faktycznie wymusza wdrożony serwer. Lista unieważnień, która nie jest odświeżana, albo kontrola roli wyłączona podczas awarii całkowicie zmieniają odpowiedź. Czytaj działającą konfigurację, a nie kopię w repozytorium.

Oceń ruch z przeszłości na jego własnych warunkach

Ujawniony plik sam nie mówi, czy wcześniej przechwycone sesje da się odszyfrować. Zależy to od metody uzgadniania kluczy, ujawnionego materiału i tego, jakie zapisy istnieją, a zarówno „cały ruch przepadł”, jak i „nic się nie stało” to domysły bez tych faktów.

Nie publikuj kolejnej kopii poświadczeń, pytając, do której kategorii należą. Zamiast tego udostępnij nazwy dyrektyw i nie-tajne metadane zatwierdzoną ścieżką wsparcia.

Użyteczny wniosek nazywa obiekt, jego rolę, utraconą ochronę i wymagane skoordynowane działanie. Wszystko krótsze jest nagłówkiem, a nie oceną.