SSL pinning aktif mi? İstemci kanıtı, kontrollü test ve sertifika yenileme planı

HTTPS sertifikası ile istemcideki pinning kontrolünü ayırın; kaynak kod, test matrisi ve anahtar dönüşümüyle doğrulanabilir bir kabul planı hazırlayın.
Bir uygulamanın HTTPS kullanması, sertifika sabitlemesinin etkin olduğunu kanıtlamaz. Sunucuya geçerli sertifika kurulmuş olabilir; buna rağmen istemci yalnızca işletim sisteminin güven deposunu kullanıyor olabilir. Tersine, bir inceleme vekilinin trafiği okuyamaması da tek başına pinning kanıtı değildir. Sağlam cevap, uygulama sürümünü, bağlantı kapsamını ve olumlu/olumsuz test sonuçlarını aynı kayıtta birleştirmektir.
- İstemciyi ve uç noktayı belirle
- Dağıtılmış yapılandırmayı incele
- Normal bağlantıyı doğrula
- Eşleşmeyen pini kontrollü sına
- Yedek anahtar ve geri dönüşü doğrula
Önce kontrolün nerede yapıldığını ayırın
Pinning kararı bağlantıyı başlatan uygulamada veya kullandığı ağ kütüphanesinde uygulanır. Güvenlik duvarındaki SSL inspection ayarı, IIS sertifika bağı veya WAF üzerindeki TLS profili aynı kontrol değildir. Temsili api.batuhanyazici.com bağlantısında hangi istemci paketinin hangi sunucu adına eriştiğini belirleyin. WebView, yerel mobil ağ istemcisi ve uygulama içindeki farklı kütüphaneler aynı güven ayarlarını paylaşmayabilir.
Android belgeleri pinning kullanımında erişilebilirlik risklerine dikkat çeker ve Android uygulamaları için bunu genel bir varsayılan öneri olarak sunmaz. Bu nedenle mevcut bir kontrolü doğrulamak ile yeni bir mimaride pinning seçmek iki ayrı karardır. Tehdit modeli ve güncelleme kabiliyeti değerlendirilmeden bütün uygulamalara aynı çözüm uygulanmamalıdır.
Kaynak kod ve dağıtım kanıtını toplayın
Yazılım ekibinden yalnızca “aktif” yanıtını istemek yerine kullanılan kütüphane, alan adı kapsamı, pin türü ve dağıtılan paket sürümünü kaydedin. Yapılandırmanın kaynak depoda bulunması üretim paketinde etkin olduğu anlamına gelmez. Derleme çeşidi, özellik bayrağı ve hata ayıklama güven ayarlarını birlikte inceleyin. Test raporuna dosya veya paket özeti eklemek, sonradan başka bir sürümün sonuçlarıyla karışmayı önler.
Açık anahtar özetini doğru yorumlayın
Android ağ güvenliği yapılandırmasındaki SPKI pinleri, sertifikanın tamamının dosya özetiyle aynı değildir. Aşağıdaki yerel örnek sunucu.pem içindeki açık anahtarın DER biçiminden SHA-256 özeti üretir. Özel anahtarı okumaz; uygulamanın bu değeri gerçekten denetlediğini de göstermez. Sertifika zincirinin hangi elemanının sabitlendiği ayrıca belirlenmelidir.
openssl x509 -in sunucu.pem -pubkey -noout > sunucu-acik-anahtar.pem
openssl pkey -pubin -in sunucu-acik-anahtar.pem -outform DER | \
openssl dgst -sha256 -binary | openssl base64 -A
Olumlu ve olumsuz testleri birlikte tasarlayın
Yetkili, ayrı bir test ortamında önce normal bağlantının başarılı olduğunu doğrulayın. Sonra güven zinciri geçerli olduğu halde beklenen pinle eşleşmeyen kontrollü bir sertifika/anahtar senaryosu oluşturun. Beklenen sonuç açıkça bağlantının reddedilmesidir. Aynı anda DNS, proxy, istemci güven deposu ve ağ erişimi hatalarını dışlayın. Aksi halde başka bir katmanın engelini pinning başarısı olarak kaydedebilirsiniz.
İnceleme vekili üzerinden uygulama verisinin okunması, test edilen sürüm ve akış için kontrolün etkisini sorgulatır. Ancak farklı bir uç noktayı veya hata ayıklama paketini test etmiş olabilirsiniz. Sunucu adını, isteğin gerçekten ulaşıp ulaşmadığını ve uygulama günlüklerindeki hata sınıfını ilişkilendirin. Gerçek kullanıcı oturumları veya müşteri verileri yerine sentetik test verisi kullanın.
Sertifika ve anahtar değişimini önceden sınayın
Mevcut bağlantı çalışırken gelecekteki anahtar dönüşümünü de planlayın. Android belgeleri yedek pinin önemini açıklar. Yeni anahtarın hangi istemci sürümlerince kabul edildiği, eski sürümlerin kullanım süresi ve dağıtım penceresi belirlenmelidir. Sertifika yenilemesinde aynı açık anahtar kullanılıp kullanılmadığına göre etkiler değişebilir; “her yenilemede bozulur” veya “hiç etkilenmez” varsayımlarından kaçının.
Geri dönüş planı, kullanıcıları sertifika doğrulamasını tamamen kapatan bir istemciye taşımak olmamalıdır. Geçerli önceki dağıtımın güvenli olarak yeniden sunulması, yedek anahtarın kullanılması veya kontrollü uygulama güncellemesi gibi seçenekleri önceden değerlendirin. Pin süresinin dolması bazı yapılandırmalarda korumanın uygulanmamasına yol açabileceğinden süre davranışını ayrıca test edin.
Kabul kaydını ölçülebilir tutun
Kayıtta uygulama sürümü, işletim sistemi, uç nokta, beklenen güven davranışı, test zamanı ve gözlenen sonuç bulunmalıdır. Başarılı normal bağlantı, eşleşmeyen pinin reddi ve dönüşüm senaryosu ayrı satırlar olmalıdır. Bu rehber bir pinning atlatma yöntemi değildir; mevcut kontrolün doğru kapsamda çalıştığını ve işletim değişiklikleri sırasında sürdürülebildiğini doğrulamaya odaklanır.
İlgili rehberler
Resmî kaynaklar ve kapsam
Kaynak kontrolü: 3 Kasım 2026. Bu rehber temsili bir laboratuvar ve yöntem anlatımıdır; belirli bir kurumda yapılmış test veya gerçekleşmiş olay iddiası taşımaz. Komutları kendi sürüm ve yetki kapsamınızda inceleyin.
Okumaya devam edin

HTTPS’e geçtim, kaynaklar neden hâlâ engelleniyor?
Mixed content uyarısını isteği yapan kaynaktan başlayarak çözmek.

TLS ve SMB sıkılaştırma: eski protokolü kapatmadan önce ve sonra ölçmek
Eski protokol bulgusunu kayıt defteri değişikliğinden öteye taşıyın: bağımlılık envanteri, pilot ve yeniden tarama.
