Czy można udostępnić publiczny klucz VPN? Sprawdź trzy rzeczy
Publikowanie publicznej połowy jest tym, jak działa protokół; publikowanie prywatnej połowy oznacza przekazanie tożsamości. Trzy kontrole decydują, którą wartość trzymasz.
Możesz przekazać swój publiczny klucz VPN partnerowi, dostawcy lub forum, a tunel nadal działa. Prywatnego klucza nie możesz przekazać, nawet personelowi wsparcia, bez przekazania tożsamości, którą ten klucz poświadcza. Decyzja rzadko pozostaje tak czysta, bo ludzie mylą, na którą połowę pary patrzą, a niektóre wdrożenia traktują wartość publiczną jak nazwę. Trzy kontrole to rozstrzygają: którą połowę masz, do czego wdrożenie ją wiąże i ile kosztuje wymiana.
Kontrola pierwsza: która połowa pary jest w schowku
Klucze asymetryczne występują w parach, a kierunek wyprowadzania jest całą istotą. W WireGuard klucz prywatny to 32 losowe bajty, a klucz publiczny jest z niego obliczany; w drugą stronę nie da się. wg genkey zapisuje wartość prywatną, wg pubkey wyprowadza publiczną, i tylko ta druga trafia do wiadomości do partnera.
wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt
Świat certyfikatów używa tego samego podziału z większą liczbą ruchomych części. Certyfikat serwera niesie klucz publiczny i nazwy, a podpisuje go prywatny klucz CA, który nigdy nie opuszcza CA. Klient weryfikujący ten serwer potrzebuje certyfikatu CA, który jest publiczny, i nie ma żadnego pożytku z prywatnego klucza podpisującego CA.
Jeśli nie masz pewności, którą wartość trzymasz, szukaj znacznika, a nie nazwy pliku. Blok PEM zaczynający się od -----BEGIN PRIVATE KEY-----, albo starsza forma BEGIN RSA PRIVATE KEY, to połowa tajna. Wartość, którą możesz wkleić bez tego znacznika, jest kandydatem do udostępnienia, z zastrzeżeniem dwóch kolejnych kontroli.
Kontrola druga: do czego wdrożenie wiąże tę wartość publiczną
Bezpieczeństwo kryptograficzne i anonimowość to różne właściwości. Publiczny klucz partnera WireGuard to stabilny identyfikator wewnątrz wdrożenia: konfiguracja serwera go wymienia, uścisk dłoni go nazywa, a administrator czytający logi widzi ten sam ciąg za każdym razem, gdy ten partner się łączy. Jeśli opublikujesz klucz obok pytania o swoją konfigurację, powiązałeś ten ciąg ze wszystkim innym w poście.
Certyfikaty ujawniają tożsamość z założenia. Subject i subject alternative name są czytelne, a w przypadku publicznie zaufanych certyfikatów TLS sam certyfikat trafia do przeszukiwalnych logów Certificate Transparency. Nic z tego nie ujawnia klucza prywatnego, a wszystko ujawnia relację.
Tu wdrożenia się różnią, i to rozstrzyga odpowiedź. Jednorazowy partner testowy na serwerze laboratoryjnym to inny obiekt niż klucz identyfikujący endpoint site-to-site firmy, choć bajty wyglądają identycznie.
Kontrola trzecia: co możesz unieważnić i jak szybko
Trzecia kontrola całkowicie rozdziela obie połowy. Opublikowany klucz publiczny można wymienić według własnego harmonogramu. Opublikowanego klucza prywatnego nie można wycofać: usunięcie własnej kopii nie dotyka kopii już przejętych, a każdy partner, który mu ufał, ufa teraz czemuś, co ma osoba z zewnątrz.
Unieważnienie to czynność konfiguracyjna, nie kryptograficzna. WireGuard nie dostarcza listy unieważnień, więc usuwasz partnera:
wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart
OpenVPN wdrożenia oparte na certyfikatach unieważniają certyfikat i publikują CRL, który serwer faktycznie sprawdza przez crl-verify. Bez tej dyrektywy lista unieważnień jest tylko ozdobą. W obu przypadkach kolejność jest ta sama: wydaj zamiennik, rozprowadź go obsługiwanym kanałem, a potem wycofaj starą tożsamość.
Błędy, które wynikają ze zlania trzech kontroli w jedną
Większość rzeczywistych wycieków to nie decyzja człowieka o publikacji klucza prywatnego. To cały profil wklejony na forum: plik .conf WireGuard z linią PrivateKey, pakiet .ovpn z wbudowanym blokiem klucza, albo zrzut okna klienta, w którym przypadkiem widać pole klucza. Wartość publiczna prawdopodobnie była w porządku; podróżowała razem z częścią, która nie była.
Procesy wsparcia to drugie źródło. Żaden legalny krok weryfikacji nie potrzebuje twojego klucza prywatnego, bo druga strona wyprowadza potrzebne dane z połowy publicznej. Gdy formularz lub osoba prosi o wartość prywatną, poprawna odpowiedź to wartość publiczna plus lokalne polecenie, które ją tworzy.
Logi i zrzuty ekranu należą do tej samej kategorii. Wynik diagnostyczny może nieść materiał klucza, identyfikatory sesji i adresy wewnętrzne, a opublikowanie tego wszystkiego, by uzyskać odpowiedź na jedno pytanie, wymienia drobną wygodę na większe narażenie.
Po wycieku wartości prywatnej wycofaj tożsamość
Jeśli wartość prywatna jednak wyszła, traktuj tę tożsamość jako wycofaną. Wygeneruj nową parę, zainstaluj połowę publiczną tam, gdzie partnerzy jej oczekują, usuń starego partnera lub unieważnij stary certyfikat i sprawdź miejsca, w których ją opublikowałeś. Nie możesz usunąć kopii, których nie kontrolujesz, więc usuwanie dotyczy przyszłości, nie przeszłości.
Potem zapisz dystrybucję: który klucz należy do którego urządzenia, kto trzyma kopię, jak dostarczany jest zamiennik i kto usuwa wycofanego partnera. To są części, o których ludzie zapominają, i one decydują, jak długo wyciek pozostaje użyteczny.