Certificate Pinning: nedir, sertifika bağlama yöntemleri ve nasıl uygulanır

Certificate Pinning'in avantajları ve dezavantajları

Certificate Pinning, mobil uygulama güvenliğini önemli ölçüde artırır ancak geliştirme ekibine operasyonel bir yük getirir. Yanlış uygulama nedeniyle bağlantı engelleme risklerine karşı güvenlik faydalarını tartmak önemlidir.

Ana avantaj, CA güvenliğinin ihlali durumları dahil olmak üzere Man-in-the-Middle saldırılarına karşı korumadır. Pinning, bir saldırgan tarafından yayınlanan sahte sertifikaları işe yaramaz hale getirir: bir CA sahteciliği imzalamış olsa bile, uygulama onu reddedecektir. Ek bir fayda, trafik incelemesi için sertifikaları değiştiren kurumsal proxy sunucularına karşı korumadır. Google Security Blog'a (2023) göre, pinning kullanan uygulamaların, yalnızca standart TLS doğrulaması kullanan uygulamalara kıyasla trafik ele geçirme yoluyla tehlikeye atılma olasılığı %86 daha düşüktür.

Pinning'in ana dezavantajı, kendini engelleme riskidir: uygulama güncellemesi yayınlanmadan önce sunucu sertifikası değişirse (yenileme, sağlayıcı değişikliği, anahtar döndürme), kullanıcılar sunucuya erişimi kaybeder. Ek dezavantajlar: hata ayıklama karmaşıklığı (her yapılandırma değişikliği pin güncellemeleri gerektirir), TrustKit kullanırken APK boyutunda 5–15 KB artış ve yeni bir sürüm olmadan değişiklikleri hızlı bir şekilde geri alamama. Riskleri en aza indirmek için yedek pinler, her 2–3 ayda bir otomatik döndürme ve uygulamanın hem eski hem de yeni sertifikayı kabul ettiği bir ödemesiz dönem kullanılır. Pinning etkinken geliştirme sırasında, ağ isteklerinde hata ayıklamak için proxy araçlarının (Burp Suite, Charles) kullanılamayacağını da dikkate almak önemlidir — geliştirme yapıları için, pinning BuildConfig.DEBUG bayrağı aracılığıyla devre dışı bırakılmalı ve QA testi, koruma etkinken yayın imzası üzerinde yapılmalıdır. Bazı ekipler, geliştirme sırasında bile korumayı sürdürmek için geliştirme ortamı için ayrı bir pinning sertifikasına sahip bir hazırlık alan adı kullanır.

Android'de Certificate Pinning uygulaması

OkHttp — ağ istekleri için standart kütüphane — kullanarak Android'de Certificate Pinning uygulamasına bir örnek bakalım. OkHttp, açık anahtarların SHA-256 hash'lerini kabul eden yerleşik bir CertificatePinner sağlar.

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

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

Yukarıdaki kodda, api.example.com alan adı için iki pin ekliyoruz: birincil (mevcut sertifika) ve bir yedek pin (döndürme için). OkHttp, sunucu sertifikasının belirtilen SHA-256 parmak izlerinden biriyle eşleşip eşleşmediğini otomatik olarak doğrular. Sertifikanın SHA-256 parmak izini almak için şu komutu kullanın: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Parmak izlerini kodda düz metin olarak değil, şifrelenmiş veya karartılmış olarak saklamak önemlidir: MobSF statik analizi, DEX dosyalarında ham SHA-256 dizelerini kolayca bulur. Pinlerin res/raw kaynaklarında AES ile şifrelenmiş olarak saklanması ve yerel kod (NDK/JNI) aracılığıyla uygulama başlangıcında çözülmesi önerilir.

TrustKit aracılığıyla iOS uygulaması

iOS'te, Certificate Pinning için birincil araç açık kaynaklı TrustKit kütüphanesidir. OkHttp'nin aksine, TrustKit Info.plist aracılığıyla bildirimsel olarak yapılandırılır ve uygulamayı yeniden derlemeden pin değişikliklerine izin verir. Yapılandırma, alan adlarına sahip bir sözlük ve SHA-256 açık anahtar parmak izleri dizisi içerir. TrustKit, NSURLSession isteklerini otomatik olarak engeller ve veri iletimi başlamadan önce sertifikaları doğrular. TrustKit'in kritik bir özelliği, pin doğrulama raporları desteğidir: kütüphane, pin uyuşmazlığı durumunda belirtilen bir uç noktaya rapor gönderebilir ve sertifika anormalliklerine hızlı yanıt verilmesini sağlar. Apple, iOS 14'ten itibaren Info.plist'te yerel bir NSPinnedDomains mekanizması da sağlar, ancak TrustKit daha esnek yapılandırma, rapor desteği ve işletim sistemi güncellemesi olmadan pinleri sıcak değiştirme yeteneği nedeniyle tercih edilen seçim olmaya devam etmektedir. TrustKit'in didReceiveChallenge delegesi aracılığıyla URLSession ile entegre olduğunu ve başarılı pin doğrulamasında .performDefaultHandling, uyuşmazlık durumunda .cancelAuthenticationChallenge döndürdüğünü belirtmek önemlidir. Pin doğrulama raporlarını izlemek için, hata sıklığını analiz eden ayrı bir uç nokta yapılandırılması önerilir: rapor sayısı keskin bir şekilde artarsa — bu, bir MitM saldırısına veya acil pin güncellemesi gerektiren yakın bir sertifika sona ermesine işaret ediyor olabilir.