Przypinanie certyfikatów w aplikacjach mobilnych i desktopowych

Standardowy TLS ufa każdemu certyfikatowi podpisanemu przez dowolny z około 150 głównych urzędów certyfikacji zainstalowanych w systemie operacyjnym. Jeśli dowolny główny urząd certyfikacji zostanie skompromitowany lub zmuszony do działania, atakujący może uzyskać certyfikat dla dowolnej domeny i przechwytywać ruch TLS. Przypinanie certyfikatów ogranicza zaufanie do konkretnego certyfikatu lub klucza publicznego, niezależnie od tego, który urząd certyfikacji go podpisał. Aplikacja z przypiętym certyfikatem odrzuca połączenia ze swoimi serwerami, chyba że serwer przedstawi dokładnie oczekiwany certyfikat lub klucz. Ochrona ta jest szczególnie cenna w aplikacjach mobilnych, w których użytkownicy nie mogą samodzielnie sprawdzać ruchu sieciowego, a firmowe rozwiązania MDM mogą instalować główne certyfikaty firmowych urzędów certyfikacji.

Wyróżnia się trzy poziomy szczegółowości przypinania: (1) Przypięcie pełnego certyfikatu — musi się zgadzać dokładnie certyfikat zakodowany w formacie DER. Jest to najbardziej podatne na problemy rozwiązanie: każda odnowa certyfikatu powoduje jego przerwanie. (2) Przypięcie klucza publicznego — porównywane są tylko bajty SubjectPublicKeyInfo (SPKI). Rozwiązanie działa po odnowieniu certyfikatu, jeśli zostanie zachowana ta sama para kluczy. (3) Skrót SPKI — przechowywany jest SHA-256(SPKI), a nie surowy klucz. Jest to podejście stosowane w HTTP Public Key Pinning (HPKP) oraz Android Network Security Config. Zaleca się przypinanie klucza publicznego lub SPKI: rozwiązanie to działa po zmianie CA i odnowieniu certyfikatu, a jednocześnie wykrywa atak MITM z użyciem innej pary kluczy.

Android (API 24+) udostępnia deklaratywny mechanizm przypinania za pośrednictwem pliku XML Network Security Config. Plik res/xml/network_security_config.xml określa przypięcia dla poszczególnych domen: pin-set z digest="SHA-256" oraz zakodowanym w base64 skrótem SPKI. Aplikacja odwołuje się do tego pliku w AndroidManifest.xml za pomocą android:networkSecurityConfig. Android wymusza przypięcia dla wszystkich połączeń HTTP wykonywanych za pośrednictwem standardowego HttpsURLConnection i OkHttp (w przypadku użycia systemowego menedżera zaufania). Element pin-set wymaga co najmniej jednego zapasowego przypięcia (innego klucza lub przypięcia CA), aby zapobiec utracie dostępu w przypadku kompromitacji klucza głównego. Wygaśnięcie przypięcia (atrybut expiration) wymusza aktualizację aplikacji, zanim przypięcia staną się nieaktualne.

Aplikacje na iOS implementują przypinanie w delegatach NSURLSession. Metoda delegata URLSession(_:didReceive:completionHandler:) otrzymuje obiekt zaufania serwera. Aplikacja wywołuje SecTrustEvaluateWithError, aby zweryfikować łańcuch, następnie wyodrębnia certyfikat końcowy za pomocą SecTrustGetCertificateAtIndex(trust, 0), eksportuje jego bajty SPKI, oblicza ich skrót SHA-256 i porównuje go z zapisanym przypięciem. TrustKit (biblioteka open source) opakowuje ten schemat w konfigurację przypinania, obsługując wiele przypięć, dopasowanie subdomen oraz tryb tylko raportowania. App Transport Security (ATS) firmy Apple jest niezależne od przypinania — ATS wymusza minimalne wersje TLS, ale nie przypina kluczy.

HTTP Public Key Pinning (HPKP, RFC 7469) miało dodać przypinanie w przeglądarkach internetowych za pomocą nagłówków odpowiedzi HTTP: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. Przeglądarka zapamiętywałaby przypięcie na czas określony przez max-age i odrzucałaby połączenia z niezgodnymi kluczami. HPKP zostało uznane przez Chrome za przestarzałe w 2017 roku i usunięte w 2019 roku z powodu katastrofalnych awarii: pojedyncza błędna konfiguracja lub utrata klucza mogła trwale zablokować użytkownikom dostęp do witryny bez możliwości odzyskania dostępu. HPKP jest obecnie w praktyce martwe w przeglądarkach internetowych; przypinanie na poziomie aplikacji mobilnych pozostaje użyteczne, ponieważ aktualizacje aplikacji mogą dostarczać nowe przypięcia.

OkHttp (powszechnie używane na Androidzie) obsługuje przypinanie za pomocą CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). Drugie przypięcie jest zapasowe. OkHttp sprawdza, czy co najmniej jedno przypięcie pasuje do dowolnego certyfikatu w łańcuchu serwera — końcowego, pośredniego lub głównego. Umożliwia to przypięcie pośredniego CA (zachowujące działanie po rotacji certyfikatu końcowego) albo głównego CA (zachowujące działanie po rotacji certyfikatu pośredniego). OkHttp zgłasza SSLPeerUnverifiedException z pomocnym komunikatem zawierającym rzeczywiste skróty SPKI serwera, dzięki czemu wyodrębnienie przypięcia podczas programowania jest proste.

Przypinanie podnosi poprzeczkę dla przechwytywania ruchu, ale nie jest niemożliwe do złamania. Typowe techniki omijania na urządzeniach mobilnych: (1) Haki Frida — wstrzyknięcie JavaScriptu do procesu aplikacji w celu przechwycenia metody weryfikującej przypięcie i bezwarunkowego zwrócenia true. (2) Narzędzia SSLUnpinning — automatyczne skrypty Frida/Objection ukierunkowane na popularne biblioteki przypinania (TrustKit, OkHttp, natywne SecTrust). (3) Niestandardowy ROM — uzyskanie uprawnień root na urządzeniu i modyfikacja stosu TLS. (4) Ponowne pakowanie — dekompilacja APK, modyfikacja konfiguracji przypinania i ponowne spakowanie z użyciem nowego certyfikatu. (5) Modyfikowanie pamięci — modyfikacja kodu bajtowego weryfikacji w czasie działania. Środki zaradcze: wykrywanie roota/jailbreaku, zaciemnianie kodu oraz kontrole integralności (SafetyNet/App Attest).

Największym ryzykiem operacyjnym przypinania certyfikatów jest zablokowanie dostępu samemu sobie: jeśli klucz produkcyjny zostanie utracony albo certyfikat wygaśnie, a kopia zapasowa będzie niedostępna, użytkownicy utracą dostęp do czasu wydania aktualizacji aplikacji (od kilku dni do kilku tygodni). Najlepsze praktyki: (1) Zawsze należy przypinać co najmniej dwa klucze — bieżący klucz oraz wcześniej wygenerowany klucz zapasowy przechowywany offline (w HSM lub w środowisku odizolowanym od sieci). (2) Należy ustawić datę wygaśnięcia przypięcia i wydać aktualizacje aplikacji przed jej nadejściem. (3) Należy monitorować nieudane przypięcia w trybie tylko raportowania przed ich wymuszeniem. (4) Należy utrzymywać awaryjny proces wydawania aktualizacji aplikacji (z przyspieszoną weryfikacją) na wypadek incydentów związanych z rotacją przypięć. (5) Należy przypinać certyfikat na poziomie pośredniego CA, a nie certyfikatu końcowego, aby umożliwić rotację certyfikatów końcowych bez aktualizacji aplikacji.

Aplikacje desktopowe napisane w Electron, Qt lub kodzie natywnym mogą implementować przypinanie za pomocą interfejsów API stosu TLS. Aplikacje Electron używają zdarzenia app.on("certificate-error") oraz session.setCertificateVerifyProc() do implementacji niestandardowej weryfikacji. Kod sieciowy Qt korzysta z QSslSocket z niestandardowym wywołaniem zwrotnym weryfikacji. Aplikacje .NET używają ServicePointManager.ServerCertificateValidationCallback. Natywne aplikacje Windows używają WinHTTP z ręczną inspekcją certyfikatów. Aplikacje desktopowe mierzą się z dodatkowymi wyzwaniami: przechwytywanie TLS na poziomie systemu operacyjnego przez firmowe proxy jest powszechne, a użytkownicy mogą oczekiwać działania proxy — dlatego należy zdecydować, czy przypinanie ma dotyczyć tylko określonych punktów końcowych.

Przypinanie certyfikatów komplikuje testy automatyczne i potoki CI/CD. Testy integracyjne wykonujące rzeczywiste połączenia HTTPS z serwerami stagingowymi muszą używać certyfikatów testowych, których skróty SPKI są przypięte w konfiguracji testowej. Możliwe podejścia: (1) Warianty kompilacji — kompilacja debug/staging zawiera przypięcia serwerów stagingowych, a kompilacja wydaniowa przypięcia produkcyjne. (2) Zastąpienia Network Security Config — Android umożliwia konfigurację przypięć wyłącznie dla kompilacji debug. (3) Serwer mock — przechwytywanie na poziomie klienta HTTP przed TLS, z całkowitym pominięciem przypinania. (4) Samopodpisany CA na potrzeby CI — wystawianie certyfikatów testowych przez urząd certyfikacji CI, którego główny certyfikat jest zaufany wyłącznie w kompilacjach testowych. Nigdy nie należy dostarczać na produkcję kompilacji z wyłączonym przypinaniem.

Przypięcia certyfikatów są zazwyczaj skrótami kluczy publicznych RSA lub EC. Gdy rozpocznie się migracja postkwantowa, serwery przejdą na ML-DSA (CRYSTALS-Dilithium) lub klucze hybrydowe. Przypięte skróty SPKI zmienią się, ponieważ zmienią się typ klucza i sposób kodowania. Aplikacje przypinające certyfikaty końcowe lub klucze publiczne będą wymagać skoordynowanych aktualizacji: (1) Należy wydać nową wersję aplikacji z postkwantowym skrótem SPKI jako zapasowym przypięciem przed migracją serwera. (2) Należy ukończyć migrację serwera. (3) Należy wydać aktualizację usuwającą stare przypięcie klasyczne. Okres przejściowy wymaga starannej koordynacji. Aplikacje przypinające pośrednie lub główne CA będą mniej podatne na skutki zmian — zmieni się tylko klucz CA, a niekoniecznie w tym samym czasie co klucze certyfikatów końcowych.

Dlaczego pinning skrótu SubjectPublicKeyInfo (SPKI) jest preferowany względem pinningu całego certyfikatu?

Pinning certyfikatu ogranicza zaufanie TLS do konkretnego certyfikatu lub klucza publicznego, chroniąc przed przejęciem urzędu certyfikacji (CA) i atakami MITM. Pinning skrótu SPKI (SHA-256 struktury SubjectPublicKeyInfo) jest preferowany względem pinningu całego certyfikatu ze względu na odporność na jego odnowienie. Android korzysta z pliku XML Network Security Config, iOS z delegata URLSession oraz interfejsów API SecTrust, a OkHttp obsługuje CertificatePinner. Należy zawsze uwzględnić zapasowy pin, aby zapobiec zablokowaniu dostępu własnej aplikacji. HPKP (nagłówek HTTP używany przez przeglądarki) został wycofany. Pinning można obejść za pomocą hooków Frida i modyfikacji ROM-u. Migracja do kluczy postkwantowych wymaga skoordynowanych aktualizacji aplikacji w celu zaktualizowania skrótów SPKI.