SSL Pinning: özü, mekanizması ve MITM saldırılarından koruma

SSL Pinning Nedir?

SSL Pinning, mobil veya web uygulamasının güvenilir bir sunucu sertifikasını veya açık anahtarı hatırladığı ve sertifikası saklananla eşleşmeyen tüm bağlantıları reddettiği bir güvenlik mekanizmasıdır. Standart HTTPS şemasında, istemci, kök CA'ya kadar olan güven zinciri aracılığıyla sertifikayı doğrular — herhangi bir CA, herhangi bir alan adı için bir sertifika imzalayabilir. SSL Pinning bu zayıflığı ortadan kaldırır: yüzlerce CA'ya güvenmek yerine, uygulama yalnızca belirli bir sertifikaya güvenir.

Standart doğrulamanın sorunu, yüzlerce kök CA'dan herhangi birinin, alan adınız için geçerli bir sertifika düzenleyebilmesidir — kazara veya zorla. Kendi kök sertifikasına sahip bir kurumsal proxy'ye erişen bir saldırgan, tarayıcı uyarısı olmadan bir MITM saldırısı gerçekleştirebilir. SSL Pinning bu güvenlik açığını kapatır: bir CA sahte sertifika düzenlese bile, parmak izi kaydedilenle eşleşmediği için uygulama onu reddedecektir.

Mobil uygulamalarda SSL Pinning özellikle önemlidir çünkü cihazlar genellikle güvenli olmayan ağlarda çalışır — halka açık Wi-Fi, trafik incelemesi olan kurumsal proxy'ler, enfekte erişim noktaları. Verizon Mobile Security Index (2025)'e göre, mobil uygulamalardaki veri ihlallerinin %60'ından fazlası, taşıma katmanındaki trafik ele geçirmeyle ilgilidir.

Mobil Geliştirmede SSL Pinning Neden Gereklidir

Mobil uygulamalar hassas veriler iletir — kimlik doğrulama belirteçleri, ödeme bilgileri, kullanıcıların kişisel verileri. Ek koruma olmadan, HTTPS, cihazda kök sertifika değiştirme yoluyla tehlikeye atılabilir — örneğin, bir kurumsal profil veya kötü amaçlı uygulama yükledikten sonra. SSL Pinning, cihazda sahte bir kök CA kurulu olsa bile, uygulamanın kendi beyaz listesine karşı sertifikayı doğrulamaya devam etmesini sağlar.

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

SSL Pinning süreci üç aşamadan oluşur: parmak izi yakalama, bağlantıda doğrulama ve hata işleme. Geliştirme sırasında, mühendis sunucu sertifikasının SHA-256 parmak izini alır (openssl x509 -fingerprint -sha256) ve bunu uygulama koduna veya yapılandırma dosyasına gömer. Her HTTPS isteğinde, uygulama alınan sertifikanın parmak izini hesaplar ve saklananla karşılaştırır — değerler eşleşmezse bağlantı sonlandırılır.

İlk aşama, derleme zamanında sabitlemedir: geliştirici sunucu sertifikalarını önceden bilir ve karmalarını gömer. İkinci aşama, ilk bağlantıda sabitlemedir (ilk kullanımda güven, TOFU): uygulama ilk istekte sertifikayı hatırlar ve sonraki tüm istekleri doğrulamak için kullanır. TOFU dinamik ortamlar için uygundur ancak ilk saldırıda savunmasızdır — ilk bağlantı zaten ele geçirilmişse, sahte sertifika güvenilir olarak kabul edilecektir.

Kritik bir detay yedek pinlerdir (backup pins). Sertifikaların bir son kullanma tarihi vardır ve değiştirildiklerinde, güncellenmemiş uygulama sunucuya bağlantısını kaybeder. Mühendisler 2–3 ek parmak izi ekler — örneğin, bir yedek sertifikanın parmak izi ve bir kök CA'nın parmak izi. Ana sertifika değişirse, uygulama yedek pinlere karşı doğrulama yapar ve bağlantı çalışmaya devam eder.

# SHA-256 sertifika parmak izini alma
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

SSL Pinning Türleri

Sabitlemeyi uygulamak için iki ana yaklaşım vardır: tüm sertifikaya bağlama (certificate pinning) ve açık anahtara bağlama (public key pinning). Her yaklaşımın güvenlik ve bakım kolaylığını etkileyen kendi güçlü yönleri ve sınırlamaları vardır.

Certificate Pinning

Sertifika sabitleme en katı yöntemdir. Uygulama, güvenilir sertifikanın veya SHA-256 parmak izinin bir kopyasını saklar ve her HTTPS bağlantısında sunucu sertifikasıyla karşılaştırır. Bu yöntem maksimum güvenlik sağlar ancak döndürme sırasında sorun yaratır — sertifikalar genellikle 1–2 yıl geçerlidir ve sonrasında zorunlu uygulama güncellemesi gerekir. Kontrollü güncelleme döngüsüne sahip kritik sistemler için önerilir.

Public Key Pinning

Açık anahtar sabitleme daha esnek bir yaklaşımdır. Uygulama, tüm sertifika yerine yalnızca sunucunun RSA veya ECDSA açık anahtarını hatırlar. Şirket aynı anahtar çiftini kullanıyorsa, sertifika yeniden düzenlendiğinde anahtar değişmeden kalabilir. Bu, uygulama güncellemelerinin sıklığını azaltır. Ancak, anahtar tehlikeye girerse, tüm istemcilerde kademeli bir değiştirme gerekli olacaktır.

iOS'ta SSL Pinning

Apple platformunda SSL Pinning, URLSession delegesi aracılığıyla uygulanır. Geliştirici, URLSessionDelegate protokolünü uygulayan bir sınıf oluşturur ve didReceive challenge yöntemini geçersiz kılar, burada saklanan parmak izlerine karşı sunucu sertifikasını manuel olarak doğrular. Alternatif bir yaklaşım, yapılandırmayı basitleştiren ServerTrustManager ile Alamofire kullanmaktır.

class SSLPinningDelegate: NSObject, URLSessionDelegate {
    let pinnedHash = "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg="

    func urlSession(_ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard let serverTrust = challenge.protectionSpace.serverTrust
            else { return completionHandler(.cancelAuthenticationChallenge, nil) }

        if validate(serverTrust, pinnedHash) {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Örnekte, delege URLSession'dan bir kimlik doğrulama isteği alır, challenge'dan serverTrust'ı çıkarır ve sertifikanın SHA-256 parmak izini saklananla karşılaştırır. Parmak izi eşleşirse — bağlantı devam eder, aksi halde challenge reddedilir. Üretim için, birden çok yedek pinin doğrulanması ve izleme için hata günlüğü eklenmesi önerilir.

iOS'ta Network Security Config

iOS 14'ten itibaren Apple, Info.plist aracılığıyla Certificate Pinning için yerleşik destek eklemiştir. Geliştirici, NSAppTransportSecurity anahtarında NSPinnedDomains alt sözlüğü ile güvenilir sertifikaları belirtir. Bu yaklaşım kod yazmayı gerektirmez ancak daha az esnektir — pinleri dinamik olarak değiştirmek veya doğrulama hatalarını günlüğe kaydetmek imkansızdır.

Android'de SSL Pinning

Android'de SSL Pinning'i uygulamanın üç ana yolu vardır: OkHttp kitaplığının CertificatePinner'ı aracılığıyla, XML'de Network Security Config aracılığıyla ve HttpsURLConnection'da özel doğrulama aracılığıyla. OkHttp, Retrofit ve diğer HTTP istemcilerinde kullanılan en popüler ve önerilen yaklaşımdır.

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // yedek pin
    .build()

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

OkHttp yapılandırmasında, geliştirici alan adını ve bir veya daha fazla SHA-256 parmak izini belirtir. İlk parmak izinde, OkHttp sunucu sertifikasını belirtilen pinlerle karşılaştırır. Eşleşme yoksa, istemci SSLPeerUnverifiedException hatası fırlatır. Bir yedek pin zorunludur — onsuz, sertifika değiştiğinde API istekleri hemen başarısız olmaya başlayacaktır.

Android'de Network Security Configuration

Android, API 24'ten itibaren XML yapılandırması aracılığıyla bildirimsel Certificate Pinning'i destekler. res/xml/network_security_config.xml dosyası, alan adlarının ve parmak izlerinin bir listesini içerir. Bu yöntem statik yapılandırmalar için uygundur ancak anormalliklerin günlüğe kaydedilmesi ile TOFU veya özel doğrulama mantığı uygulanmasına izin vermez.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">
                Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=</pin>
            <pin digest="SHA-256">
                FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

SSL Pinning'in Avantajları ve Dezavantajları

SSL Pinning, mobil uygulamanın güvenliğini önemli ölçüde artırır ancak operasyonel karmaşıklıklar getirir. Ana avantaj, kök CA'lar tehlikeye girse bile MITM saldırılarına karşı korumadır. Uygulama, genel sertifika yetkililerinin tüm altyapısına değil, yalnızca geliştirici tarafından açıkça belirtilen sertifikalara güvenir. Bu, özellikle finansal uygulamalar, mesajlaşma uygulamaları ve hassas verilere sahip uygulamalar için kritiktir.

Ana dezavantaj, sertifika döndürmenin karmaşıklığıdır. Bir sertifikanın süresi dolarsa veya iptal edilirse, uygulamayı güncellemeyen kullanıcılar bağlantıyı kaybeder. Bu, yedek pinler ve kademeli güncelleme mekanizması ile çözülür: yeni uygulama hem eski hem de yeni sertifikaları bilir ve kullanıcıların tam güncellemesinden sonra eski pin koddan kaldırılır. En az 2 yedek pin eklenmesi önerilir — biri mevcut sertifika için, diğeri gelecek için.

Diğer bir ödünleşim, sabitlemeyi devre dışı bırakmadan trafik hata ayıklaması (Charles Proxy, Burp Suite) için genel proxy'leri kullanamamaktır. Bu, geliştirme sırasında ağ isteklerinin hata ayıklamasını zorlaştırır. Çözüm, koşullu derlemedir: hata ayıklama yapılarında sabitleme devre dışıdır, sürüm yapılarında etkindir. OWASP, geçiş için BuildConfig.DEBUG bayrağının kullanılmasını önerir.