Własny certyfikat VPN to nie dodatkowa warstwa szyfrowania
Certyfikat zmienia tożsamość i zaufanie, a nie liczbę warstw szyfrowania. Zdecyduj, pytając, co i gdzie się kończy.
Instalacja własnego certyfikatu na punkcie końcowym VPN wydaje się dodawać ochronę, bo certyfikaty i szyfrowanie wszędzie występują razem. W praktyce zmienia dwie rzeczy: tożsamość, którą przedstawia punkt końcowy, oraz to, któremu wystawcy jego partner jest gotów zaufać. Żadna z nich nie opakowuje danych po raz drugi. Jeśli rzeczywistą potrzebą jest drugi chroniony kanał, potrzebny jest drugi kanał z własnymi punktami końcowymi, a nie kolejny certyfikat.
Trzy odrębne zadania w uścisku TLS 1.3
RFC 8446 oddziela te rzeczy, i właśnie ten podział jest całą odpowiedzią. Komunikat Certificate przenosi łańcuch certyfikatów punktu końcowego. CertificateVerify dowodzi posiadania pasującego klucza prywatnego i wiąże transkrypt uścisku. Warstwa rekordów chroni ruch za pomocą wynegocjowanych kluczy ruchu.
Wymień certyfikat, a pierwsze dwie pozycje się zmieniają. Ochrona rekordów nie działa dwa razy i nie staje się silniejsza tylko dlatego, że wystawca jest teraz prywatny.
Co właściwie daje prywatne CA
Daje kontrolowany system tożsamości: decydujesz, komu wydawane są certyfikaty, decydujesz, których wystawców akceptują partnerzy, i możesz unieważniać według własnego harmonogramu. To naprawdę przydatne, gdy zarządzasz oboma końcami.
Wnosi jednak także obowiązki. Zaufanie trzeba rozdzielać świadomie, weryfikacja partnera musi pozostać włączona, a cyklem życia poświadczeń musi ktoś zarządzać. Prywatne CA nie jest skrótem omijającym którąkolwiek z tych trzech rzeczy.
Kiedy drugi kanał jest właściwą odpowiedzią
Załóżmy, że aplikacja otwiera zweryfikowane HTTPS do własnej usługi, a jej pakiety wędrują także przez VPN. Taki projekt ma dwie granice z potencjalnie różnymi punktami końcowymi, i tak właśnie wygląda drugi chroniony kanał.
Różnica ma znaczenie na bramie. Jeśli sesja TLS aplikacji kończy się na bramie VPN, a nie w aplikacji, ochrona, którą rzekomo miało się za tunelem, nie jest tam obecna. Zapisz, kto kończy każdy kanał, zanim zgłosisz tę właściwość.
Zapytaj, co zmienia instalacja
Wniosek o instalację certyfikatu może oznaczać trzy różne rzeczy. Może zmienić tożsamość samego klienta, kotwicę zaufania właściwą dla aplikacji albo zaufanie na poziomie platformy do wszystkiego na urządzeniu. To nie jest równoważne, a tylko ostatnie wpływa na niezwiązane oprogramowanie.
Zapytaj, które z trzech jest zamierzone, a potem, co ma osiągnąć. Jeśli odpowiedzią jest więcej szyfrowania, propozycja mierzy w niewłaściwy mechanizm.
Zapisz granice
Dla każdego kanału zapisz punkty końcowe, tożsamość weryfikowaną przez każdą stronę i to, co widzi operator pośrodku. Następnie zapisz zachowanie przy awarii: co się dzieje, gdy weryfikacja zawiedzie, i co, gdy kanał zostanie odrzucony.
Dwie linijki na jednej stronie zwykle rozstrzygają spór, którego rotacja certyfikatów nie rozstrzygnie.
Zdecyduj trzema pytaniami
Czy problem dotyczy tego, kim punkt końcowy się mieni, czy tego, co dzieje się z danymi? Czy ochrona musi trwać za bramą VPN aż do konkretnej aplikacji? I czy potrafisz wymienić dwa punkty końcowe, które zakończyłyby drugi kanał?
Jeśli prawdziwe jest pierwsze pytanie, napraw tożsamość i zaufanie. Jeśli drugie lub trzecie, zaprojektuj drugi kanał i zostaw certyfikat tam, gdzie jego miejsce.