Certificate Pinning: co to jest, metody wiązania certyfikatów i jak zaimplementować

Zalety i wady Certificate Pinning

Certificate Pinning znacząco zwiększa bezpieczeństwo aplikacji mobilnej, ale nakłada obciążenie operacyjne na zespół deweloperski. Ważne jest, aby rozważyć korzyści ochrony i ryzyko blokady połączenia przy nieprawidłowej implementacji.

Główną zaletą jest ochrona przed atakami Man-in-the-Middle, w tym przypadkami kompromitacji CA. Pinning uniemożliwia użycie fałszywych certyfikatów wydanych przez atakującego: nawet jeśli CA podpisał podróbkę, aplikacja ją odrzuci. Dodatkowym plusem jest ochrona przed korporacyjnymi serwerami proxy, które podmieniają certyfikaty do inspekcji ruchu. Według Google Security Blog (2023), aplikacje z pinning mają o 86% mniejsze szanse na włamanie przez przechwycenie ruchu w porównaniu z aplikacjami używającymi tylko standardowej weryfikacji TLS.

Główną wadą pinning jest ryzyko samo-blokady: jeśli certyfikat serwera zmienia się (przedłużenie, zmiana dostawcy, rotacja kluczy) przed wydaniem aktualizacji aplikacji, użytkownicy tracą dostęp do serwera. Dodatkowe minusy: trudność debugowania (przy każdej zmianie ustawień trzeba aktualizować piny), zwiększenie rozmiaru APK o 5–15 KB przy użyciu TrustKit oraz brak możliwości szybkiego wycofania zmian bez nowej wersji. Aby zminimalizować ryzyko, stosuje się zapasowe piny, automatyczną rotację co 2–3 miesiące i okres przejściowy (grace period), w którym aplikacja akceptuje zarówno stary, jak i nowy certyfikat. Należy również pamiętać, że przy włączonym pinning podczas programowania nie można używać narzędzi proxy (Burp Suite, Charles) do debugowania żądań sieciowych — dla wersji deweloperskich pinning powinien być wyłączony poprzez flagę BuildConfig.DEBUG, a testy QA powinny być przeprowadzane na sygnaturze wydaniowej z włączoną ochroną. Niektóre zespoły używają domeny staging z oddzielnym certyfikatem pinning dla środowiska deweloperskiego, aby zachować ochronę nawet na etapie programowania.

Implementacja Certificate Pinning w Android

Rozważmy przykład wdrożenia Certificate Pinning na Android z użyciem OkHttp — standardowej biblioteki do żądań sieciowych. OkHttp udostępnia wbudowany CertificatePinner, który przyjmuje hasze SHA-256 kluczy publicznych.

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .add(
        "api.example.com",
        "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

W powyższym kodzie dodajemy dwa piny dla domeny api.example.com: główny (bieżący certyfikat) i zapasowy (na wypadek rotacji). OkHttp automatycznie sprawdza, czy certyfikat serwera jest zgodny z jednym z podanych odcisków SHA-256. Aby uzyskać odcisk SHA-256 certyfikatu, używa się polecenia: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Ważne jest, aby przechowywać odciski nie w otwartej postaci w kodzie, ale zaszyfrowane lub zaciemnione: statyczna analiza MobSF łatwo znajduje gołe ciągi SHA-256 w plikach DEX. Zaleca się przechowywanie pinów w zasobach res/raw, zaszyfrowanych przez AES, i odszyfrowywanie ich przy starcie aplikacji przez kod natywny (NDK/JNI).

Implementacja na iOS przez TrustKit

Na iOS głównym narzędziem Certificate Pinning jest biblioteka TrustKit z otwartym kodem źródłowym. W przeciwieństwie do OkHttp, TrustKit konfiguruje się deklaratywnie przez Info.plist, co pozwala zmieniać piny bez rekompilacji aplikacji. Konfiguracja zawiera słownik z domenami i tablicą odcisków SHA-256 kluczy publicznych. TrustKit automatycznie przechwytuje żądania NSURLSession i sprawdza certyfikaty przed rozpoczęciem przesyłania danych. Kluczową cechą TrustKit jest obsługa raportów weryfikacji pinów: biblioteka może wysyłać raporty do określonego endpointu przy niezgodności pinu, co pozwala szybko reagować na anomalie certyfikatów. Apple udostępnia również natywny mechanizm NSPinnedDomains w Info.plist od iOS 14, ale TrustKit pozostaje preferowanym wyborem ze względu na bardziej elastyczną konfigurację, obsługę raportów i możliwość gorącej wymiany pinów bez aktualizacji systemu. Należy zauważyć, że TrustKit integruje się z URLSession przez delegata didReceiveChallenge, zwracając .performDefaultHandling przy pomyślnej weryfikacji pinu i .cancelAuthenticationChallenge przy niezgodności. Do monitorowania raportów weryfikacji pinów zaleca się skonfigurowanie oddzielnego endpointu, który analizuje częstotliwość błędów: jeśli liczba raportów gwałtownie wzrasta — może to wskazywać na atak MitM lub zbliżające się wygaśnięcie certyfikatu, wymagające natychmiastowej aktualizacji pinów.