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

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.

Ö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

• TLS sertifikası ve yenileme yaşam döngüsü
• Cloudflare WAF yanlış pozitif incelemesi

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: Yazıda belirtilen ürün ve desteklenen pilot ortam — Yetkili izole pilot, belirtilen sürüm/model desteği, mevcut durum kaydı ve değişiklik gerekiyorsa tutarlı yedek/geri erişim gerekir.

1. Pinning iddiasını gerçek istemciyle doğrulayın
2. İzinli sertifikadan SPKI pinini çıkarın
3. Normal trust ve pin kontrolünü birlikte sınayın
4. Gerçek uygulamada negatif senaryoyu kabul edin
5. Rotation ve geri dönüşü planlayın

1. Pinning iddiasını gerçek istemciyle doğrulayın

Sunucu sertifikasının görünmesi mobil/desktop istemcinin pinning uyguladığını kanıtlamaz. İstemci sürümü/kod/config, trust store ve hangi leaf/intermediate SPKI’nin pinlendiği kaydedilir.

2. İzinli sertifikadan SPKI pinini çıkarın

OpenSSL örneği sertifikanın public key’ini hash’ler; private key kullanılmaz. Elde edilen pin sadece bu eğitimsel curl kabulüne aittir.

pin=$(openssl x509 -in batuhanyazici-server.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | openssl base64 -A)
printf '%s\n' "$pin"

3. Normal trust ve pin kontrolünü birlikte sınayın

Public CA güveni hazır olmalı; private CA gerekiyorsa doğru –cacert dosyasını ekleyin. Pinning chain/hostname doğrulamasının yerine geçmez; –insecure kullanmayın.

curl --pinnedpubkey "sha256//$pin" -I https://lab.batuhanyazici.com/
# Bilerek yanlis ama bicimsel olarak gecerli pin: basarisizlik beklenir.
curl --pinnedpubkey 'sha256//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=' -I https://lab.batuhanyazici.com/

4. Gerçek uygulamada negatif senaryoyu kabul edin

Yalnız yetkili laboratuvar trust/sertifika değişimiyle gerçek istemcinin beklenen reddini ölçün. curl denemesi özel uygulamanın kodunu test etmez; ikisini ayrı raporlayın. Logda URL/token gibi özel verileri ayıklayın.

5. Rotation ve geri dönüşü planlayın

Sertifika yenilenmesiyle key/SPKI değişimini ayırın; desteklenen istemcide yeni ve yedek pinlerin kademeli dağıtımı gerekir. Eski ele geçmiş key’i geri dönüş diye kullanmayın; güncel kabul edilmiş trust/pin takımına dönün.

Beklenen sonuç: Doğru SPKI pin+trust testi geçer, yanlış pin reddedilir; gerçek uygulama pinning’i ayrıca doğrulanır.

Sonuç farklıysa: Başarısız aşamada durun; ilgili kayıt/ürün sürümü/ön koşulu inceleyin. Farklı katmanı genel olarak sıfırlamak yerine tek nedeni ayırın.

Geri dönüş: Yalnız bu işlemde değişen öğeyi önceki uyumlu sürüm veya açıkça belirtilen yedek/restore planıyla geri alın; geri alınamaz veri/disk işlemlerini ayar geri dönüşü sanmayın.