Przypinanie TLS i dostęp VPN odpowiadają na różne pytania

Umieść prywatną aplikację mobilną za VPN, a rozsądny człowiek zapyta, czy nadal potrzebuje przypinania certyfikatów. Pytanie brzmi jak wybór między dwiema równoważnymi kontrolami, a naprawdę dotyczy dwóch różnych bram. VPN decyduje, czy to urządzenie w ogóle może korzystać ze ścieżki; aplikacja decyduje, czy osiągnięty serwer jest tym oczekiwanym. Odpowiedz na oba osobno, a projekt stanie się prostszy.

Dwie bramy, dwa pytania

Dopuszczenie do sieci dotyczy klienta: czy to urządzenie jest zarejestrowane, czy jego poświadczenie jest ważne i czy polityka pozwala mu wejść na tę ścieżkę? Zaufanie aplikacji dotyczy serwera: czy połączenie dotarło do usługi o tożsamości, którą aplikacja akceptuje? Te odpowiedzi pochodzą z różnych systemów, zawodzą z różnych powodów i poprawiają je różne zespoły. Uścisk dłoni VPN może się udać, podczas gdy aplikacja rozmawia z wygasłym certyfikatem za pearem. Doskonale przypięta aplikacja może mimo to być nieosiągalna dla nikogo, bo urządzenie nigdy nie trafiło do sieci.

Oba się sumują. Pominięcie jednego usuwa kontrolę; dodanie drugiego go nie zastępuje.

Co przypięcie naprawdę ogranicza

Przypięcie zawęża zbiór tożsamości serwera, które aplikacja zaakceptuje, zwykle wskazując klucz publiczny lub skrót certyfikatu zamiast ufać każdemu łańcuchowi, za który poręczyłby jakiś magazyn. To ograniczenie nałożone na zwykłą walidację, a nie jej zamiennik. Zwykła walidacja odpowiada, czy łańcuch jest w ogóle godny zaufania; przypięcie odpowiada, czy to ten łańcuch, którego oczekuje ta aplikacja. Implementacja, która pomija pierwszy krok, nie zyskała bezpieczeństwa, tylko nowości.

Przypinany obiekt różni się między platformami, więc samo słowo mówi bardzo niewiele. Skopiowanie skrótu z magazynu zaufania jednego produktu i potraktowanie go jako tego samego w aplikacji mobilnej to częsty i cichy błąd.

Przypinanie na platformie to konfiguracja, nie polityka

Android udostępnia przypinanie przez swoją konfigurację bezpieczeństwa sieci, gdzie zbiór przypięć przechowuje skróty klucza publicznego, a łańcuch musi zawierać co najmniej jeden z nich. Ten plik jest dla każdej aplikacji i wymaga świadomej zmiany kompilacji. iOS nie ma równoważnego mechanizmu manifestu, więc przypinanie żyje tam we własnym kodzie oceny zaufania aplikacji.

Ponieważ mechanizm się różni, wymóg trzeba pisać dla każdej platformy. Polityka, która mówi przypnij certyfikat bez wskazania platformy, nie jest wykonalna.

Rotacja decyduje, czy przypięcie przetrwa

Trudna część to nie pierwsze wydanie, lecz odnawianie certyfikatu po nim. Restrykcyjna polityka zaufania odrzuca uzasadniony nowy klucz równie stanowczo jak klucz atakującego.

Dwa mechanizmy czynią rotację do przetrwania: zapasowe przypięcie, któremu ufa się już przed potrzebą, oraz data wygaśnięcia w zbiorze przypięć, aby egzekwowanie wygasało, a nie blokowało aplikację. Oba są decyzjami polityki, a wygaśnięcie w szczególności jest świadomym obniżeniem bezpieczeństwa, nie nieszkodliwym zegarem. Wskaż, kto kontroluje kompilację aplikacji, punkt końcowy TLS i odnawianie certyfikatu, i połącz ich w jeden proces zmian. Jeśli to trzy różne zespoły, przypięcie w końcu spowoduje awarię, której nikt nie zaplanował.

Zgubione urządzenie to trzeci problem

Odwołanie poświadczenia VPN nie kończy automatycznie sesji aplikacji, a przypięcie serwera nie robi absolutnie nic z telefonem w cudzej ręce. Blokada urządzenia, przechowywanie poświadczeń, czas życia sesji i zdalne odwołanie to osobne decyzje z osobnymi właścicielami. Złożenie ich w dyskusję o przypinaniu gwarantuje, że żadna z nich nie zostanie zaprojektowana.

Przetestuj cztery relacje zamiast tej jednej, którą widzisz: zamierzony serwer i operację, konto, które powinno zostać odrzucone, tożsamość serwera, która powinna zostać odrzucona, i zaplanowaną rotację. Działający VPN ćwiczy tylko pierwszą. Zapisz, co dowiódł każdy test, bo następna osoba uzna, że zielony tunel oznacza, iż wszystkie cztery przeszły.