Certificate Pinning: nedir, mekanizması ve sabitleme yöntemleri

Certificate Pinning Nedir?

Certificate Pinning, bir uygulamanın güvenilir bir sertifikanın parmak izini sakladığı ve HTTPS bağlantısı kurmak için bunu tek kriter olarak kullandığı bir güvenlik tekniğidir. Standart TLS modelinde, istemci sunucu sertifikasının güvenilir bir kök CA tarafından imzalandığını doğrular — sistemde önceden yüklü yüzlerce sertifika yetkilisinden herhangi biri. Certificate Pinning bu zinciri doğrudan bir kontrole dönüştürür: sertifika, saklanan örnekle eşleşmeli veya beklenen açık anahtarı içermelidir.

Standart modelin sorunu, CA ihlali olaylarından sonra belirgin hale geldi — DigiNotar (2011), Comodo (2011), TrustCor (2022). Bir CA, alan adınız için sahte bir sertifika düzenlerse, tarayıcı veya uygulama bunu geçerli olarak kabul eder. Certificate Pinning bu saldırıyı önler: mükemmel imzalanmış sahte bir sertifika bile, parmak izi uygulamada sabitlenenle eşleşmediği için reddedilecektir.

Pinning terimi, pin — “iğne” veya “sabitleyici” — kelimesinden gelir: geliştirici güvenilir bir sertifikayı sabitler ve bundan herhangi bir sapma bağlantıyı engeller. Mitre CWE-295 araştırmasına göre, uygun olmayan sertifika doğrulaması, mobil uygulamalardaki en tehlikeli ilk 10 güvenlik hatası arasında yer almaya devam etmektedir ve Certificate Pinning bunu önlemenin doğrudan bir yöntemidir.

Certificate Pinning'in Tarihi ve Evrimi

Başlangıçta, Certificate Pinning, RFC 7469'da standartlaştırılan HPKP (HTTP Public Key Pinning) mekanizması aracılığıyla tarayıcılarda kullanılıyordu. Geliştirici, beklenen anahtarların hash'lerini içeren bir HTTP Public-Key-Pins başlığı gönderir ve tarayıcı bunları belirtilen bir süre boyunca saklardı. Ancak HPKP tehlikeli olduğu ortaya çıktı: tek bir yapılandırma hatası bir siteyi aylarca engelleyebilirdi. 2018'de Chrome, HPKP desteğini sonlandırdı ve mevcut standart istemci tarafı uygulama — bir mobil uygulama veya tarayıcı uzantısı içinde — haline geldi.

Certificate Pinning Nasıl Çalışır?

Certificate Pinning süreci üç temel aşamayı içerir: parmak izi hesaplama, bağlantı doğrulama ve hata yönetimi. Hazırlık aşamasında, geliştirici üretim sunucusunun sertifikasının veya açık anahtarının SHA-256 hash'ini alır. GDPR ve PCI DSS uyumlu uygulamalar için, zincirdeki ara CAların parmak izlerini de sabitlemek gerekir.

Her HTTPS isteğinde, uygulama TLS kimlik doğrulama geri çağrımını yakalar, sunucunun sertifikasını çıkarır ve SHA-256 hash'ini hesaplar. Bu hash, saklanan güvenilir parmak izleri listesiyle karşılaştırılır. Bir eşleşme bulunursa — bağlantı devam eder. Bulunmazsa — uygulama bağlantıyı sonlandırmalı ve saldırgana uygulama ayrıntılarını ifşa etmeden hatayı bildirmelidir.

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

Fonksiyon, sunucudan bir X509Certificate nesnesi ve beklenen hash'i alır. Önce sertifikanın açık anahtarını çıkarır, SHA-256 hash'ini hesaplar ve Base64'e kodlar. Sonuç, beklenen parmak izi ile karşılaştırılır. Üretimde, rotasyonu desteklemek için 2–3 parmak izinden oluşan bir diziye karşı doğrulama eklemek gerekir.

Certificate Pinning vs Public Key Pinning

Pinning uygularken, hangi kriptografik nesnenin sabitleneceğini seçmek gerekir. Certificate Pinning, X.509 sertifikasının kendisine — seri numarasına, geçerlilik süresine ve tüm zincire — bağlanır. Public Key Pinning, sertifika içindeki yalnızca açık anahtarı sabitler, diğer alanları görmezden gelir. Bu seçim, işletme maliyetlerini önemli ölçüde etkiler.

Public Key Pinning çoğu proje için tercih edilen seçimdir. Sertifika yeniden düzenlenirken sunucuların açık anahtarları genellikle değişmez — şirket eski anahtarı yeni bir sertifikayla imzalar. Bu, anahtar çifti değişmemişse, sertifika değişikliğinden sonra uygulamanın güncelleme gerektirmediği anlamına gelir. Öte yandan Certificate Pinning, geliştiricinin hem sunucuyu hem de istemci kodunu tamamen kontrol ettiği senaryolarda — örneğin sıkı güncelleme döngüsüne sahip kurumsal uygulamalarda — önerilir.

Trust On First Use (TOFU)

TOFU, Certificate Pinning'in önceden yapılandırılmadığı, bunun yerine sunucuya ilk bağlantıda sertifikayı hatırladığı bir stratejidir. Bu yaklaşım, önceden hangi sunucuya bağlanacağını bilmeyen uygulamalar için uygundur. Dezavantajı, ilk saldırıya karşı savunmasızlıktır: ilk bağlantı ele geçirilirse, sahte bir sertifika güvenilir olarak kabul edilecektir. TOFU, SSH bağlantılarında ve bazı P2P protokollerinde kullanılır.

iOS ve Android'de Uygulama

Her iki platformda da Certificate Pinning, ağ yığı seviyesinde TLS bağlantısını yakalayarak uygulanır. iOS'ta URLSession delegesi veya Alamofire ServerTrustManager kullanılır. Android'de tercih edilen yöntem, popüler HTTP istemcilerine yerleşik olan ve her alan adı için birden çok parmak izi yapılandırmasını destekleyen OkHttp CertificatePinner'dır.

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

Swift fonksiyonunda, serverTrust'tan sertifika zinciri çıkarılır, her sertifika için SHA-256 hash'i hesaplanır ve sonuç beklenenle karşılaştırılır. Zincirdeki tüm sertifikalar arasında gezinmek, ara CA seviyesinde pinning uygulamaya olanak tanır — bir ara sertifika eşleşirse bağlantı kabul edilir. Bu, yaprak sertifika rotasyonu sırasında esneklik sağlar.

Android için Özel TrustManager

Uygulama OkHttp kullanmıyorsa, Certificate Pinning özel bir X509TrustManager aracılığıyla uygulanabilir. Bu yöntem daha fazla kod gerektirir ancak doğrulama süreci üzerinde tam kontrol sağlar. TrustManager, geliştiricinin sunucu sertifikalarını manuel olarak doğruladığı ve güvenip güvenmeyeceğine karar verdiği checkServerTrusted yöntemini geçersiz kılar. Yalnızca OkHttp kütüphanesinin mevcut olmadığı belirli senaryolarda önerilir.

Certificate Pinning Uygulamasında Sık Yapılan Hatalar

En yaygın hata, yedek pinlerin olmamasıdır. Geliştirici tek bir sertifika parmak izi ekler ve süresi dolduğunda kullanıcılar toplu halde bağlantıyı kaybeder. Kabul edilebilir minimum yapılandırma iki parmak izidir: mevcut sertifika ve bir yedek. İdeal olarak üç: mevcut, bir yedek ve yedek olarak kök CA parmak izi.

İkinci hata, pinlerin kodda düz metin olarak saklanmasıdır. APK veya IPA'ya erişimi olan bir saldırgan, parmak izlerini kolayca çıkarıp değiştirebilir. Hash karartma önerilir: dizeyi parçalara ayırın, şifrelenmiş kaynaklarda saklayın veya çalışma zamanında hesaplayın. Android için, dize sabiti karartma ile ProGuard etkilidir.

Üçüncü hata, geliştirme sertifikası seviyesinde pinning yapmaktır. Geliştirme ve üretim sertifikaları genellikle farklıdır, ancak geliştiriciler genellikle bir sürüm derlerken pinleri değiştirmeyi unutur. Sonuç olarak, üretim uygulaması sunucuya bağlanamaz. Çözüm, BuildConfig veya flavor'a özgü kaynaklar aracılığıyla hata ayıklama ve sürüm için ayrı pin yapılandırmalarıdır.

• Sertifika zincirini görmezden gelme — ara CAları dikkate almadan yalnızca yaprak sertifikayı kontrol etme, rotasyon sırasında bağlantıyı keser
• Sert kodlanmış tarihler — güncellemelerden sonra değişmeyen sert kodlanmış sertifika son kullanma tarihleri
• İzleme yok — Certificate Pinning hatalarıyla ilgili uyarıların olmaması, sorunların yalnızca kullanıcılardan keşfedilmesi
• Doğrulama olmadan TOFU — ek doğrulama olmadan Trust On First Use kullanma, ilk MITM saldırısının sahte bir sertifikayı sabitlemesine izin verme