Mobil ve Masaüstü Uygulamalarında Sertifika Sabitleme

Standart TLS, OS'ye önceden yüklenmiş yaklaşık 150 kök CA'dan herhangi biri tarafından imzalanmış tüm sertifikalara güvenir. Herhangi bir kök CA ele geçirilir veya zorlanırsa saldırgan, herhangi bir alan adı için sertifika alabilir ve TLS trafiğini araya girerek ele geçirebilir. Sertifika sabitleme, hangi CA'nın imzaladığından bağımsız olarak güveni belirli bir sertifika veya genel anahtarla sınırlar. Sabitleme kullanan bir uygulama, sunucu tam olarak beklenen sertifikayı veya anahtarı sunmadıkça sunucularına yapılan bağlantıları reddeder. Bu koruma, kullanıcıların ağ trafiğini inceleyemediği ve kurumsal MDM çözümlerinin kurumsal CA kökleri yükleyebildiği mobil uygulamalar için özellikle değerlidir.

Sabitlemenin üç ayrıntı düzeyi vardır: (1) Tam sertifika sabitlemesi — DER kodlamalı sertifikanın aynısı eşleşmelidir. Bu yaklaşım en kırılgan olanıdır; herhangi bir sertifika yenilemesinde bozulur. (2) Genel anahtar sabitlemesi — yalnızca SubjectPublicKeyInfo (SPKI) baytları karşılaştırılır. Aynı anahtar çifti korunursa sertifika yenilemesinden etkilenmez. (3) SPKI karması — ham anahtar yerine SHA-256(SPKI) saklanır. HTTP Genel Anahtar Sabitlemesi (HPKP) ve Android Ağ Güvenliği Yapılandırması yaklaşımı budur. Genel anahtar / SPKI sabitlemesi tercih edilir; CA'nın değiştirilmesinden ve sertifika yenilemesinden etkilenmeden, farklı bir anahtar çiftiyle gerçekleştirilen MITM saldırılarını algılamayı sürdürür.

Android (API 24 ve üzeri), Ağ Güvenliği Yapılandırması XML'i aracılığıyla bildirime dayalı bir sabitleme mekanizması sağlar. res/xml/network_security_config.xml dosyası, alan adı başına sabitlemeleri belirtir: digest="SHA-256" içeren pin-set ve base64 ile kodlanmış SPKI karması. Uygulama bu dosyaya AndroidManifest.xml içinde android:networkSecurityConfig aracılığıyla başvurur. Android, standart HttpsURLConnection ve OkHttp üzerinden yapılan tüm HTTP bağlantılarında (platform güven yöneticisi kullanıldığında) sabitlemeleri uygular. Birincil anahtarın ele geçirilmesi durumunda uygulamanın kilitlenmesini önlemek için pin-set en az bir yedek sabitleme (farklı bir anahtar veya CA sabitlemesi) gerektirir. Sabitleme süresinin dolması (expiration özniteliği), sabitlemeler geçerliliğini yitirmeden önce uygulamaların güncellenmesini zorunlu kılar.

iOS uygulamaları, NSURLSession temsilcilerinde sabitleme uygular. URLSession(_:didReceive:completionHandler:) temsilci yöntemi sunucunun güven nesnesini alır. Uygulama, zinciri doğrulamak için SecTrustEvaluateWithError çağrısını yapar; ardından yaprak sertifikayı SecTrustGetCertificateAtIndex(trust, 0) ile çıkarır, SPKI baytlarını dışa aktarır, SHA-256 ile karmalar ve kayıtlı sabitlemeyle karşılaştırır. TrustKit (açık kaynaklı kitaplık), bu yaklaşımı yapılandırma tabanlı sabitlemeyle kapsar; birden çok sabitlemeyi, alt alan adı eşleştirmeyi ve yalnızca raporlama kipini destekler. Apple'ın App Transport Security (ATS) özelliği sabitlemeden ayrıdır; ATS, TLS sürümü alt sınırlarını uygular ancak anahtarları sabitlemez.

HTTP Genel Anahtar Sabitlemesi (HPKP, RFC 7469), HTTP yanıt üst bilgileri aracılığıyla web tarayıcılarına sabitleme eklemeyi amaçlıyordu: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. Tarayıcı, sabitlemeyi max-age süresi boyunca hatırlar ve anahtarları eşleşmeyen bağlantıları reddederdi. HPKP, tek bir yanlış yapılandırmanın veya anahtar kaybının kullanıcıların kurtarma yolu olmadan bir web sitesine erişimini kalıcı olarak engelleyebilmesi nedeniyle Chrome tarafından 2017'de kullanımdan kaldırıldı ve 2019'da kaldırıldı. HPKP artık web tarayıcıları açısından fiilen kullanılmamaktadır; mobil uygulamalardaki uygulama düzeyi sabitleme ise uygulama güncellemeleri yeni sabitlemeleri içerebildiği için hâlâ uygulanabilir durumdadır.

Android'de yaygın olarak kullanılan OkHttp, CertificatePinner aracılığıyla sabitlemeyi destekler: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). İkinci sabitleme yedektir. OkHttp, sunucu zincirindeki herhangi bir sertifikayla — yaprak, ara veya kök sertifikayla — en az bir sabitlemenin eşleştiğini doğrular. Bu sayede ara CA'ya sabitleme (yaprak sertifikaların yenilenmesine dayanır) veya kök CA'ya sabitleme (ara sertifikaların yenilenmesine dayanır) yapılabilir. OkHttp, sunucunun gerçek SPKI karmalarını listeleyen açıklayıcı bir iletiyle SSLPeerUnverifiedException oluşturur; bu da geliştirme sırasında sabitlemeleri çıkarmayı kolaylaştırır.

Sabitleme, trafiği ele geçirmeyi zorlaştırır ancak aşılamaz değildir. Mobil cihazlarda kullanılan yaygın atlatma teknikleri şunlardır: (1) Frida kancaları — uygulama sürecine JavaScript enjekte ederek sabitleme doğrulama yöntemini kancalamak ve koşulsuz olarak true döndürmek. (2) SSLUnpinning araçları — yaygın sabitleme kitaplıklarını (TrustKit, OkHttp, yerel SecTrust) hedefleyen otomatik Frida/Objection betikleri. (3) Özel ROM — cihaza kök erişimi sağlamak ve TLS yığınını değiştirmek. (4) Yeniden paketleme — APK'nın kaynak koduna dönüştürülmesi, sabitleme yapılandırmasının değiştirilmesi ve yeni bir sertifikayla yeniden paketlenmesi. (5) Bellek yamalama — doğrulama bayt kodunun çalışma zamanında değiştirilmesi. Karşı önlemler: kök erişimi/hapisten çıkarma algılama, kod gizleme ve bütünlük denetimleri (SafetyNet/App Attest).

Sertifika sabitlemesindeki en büyük işletimsel risk, kendi kendini kilitlemedir: üretim anahtarı kaybolur veya sertifikanın süresi dolar ve yedek kullanılamazsa, bir uygulama güncellemesi yayımlanana kadar (günlerden haftalara uzanan bir süre) kullanıcıların erişimi engellenir. En iyi uygulamalar şunlardır: (1) Her zaman en az iki anahtarı sabitleyin — geçerli anahtarı ve çevrimdışı (HSM'de veya internetten yalıtılmış biçimde) saklanan, önceden oluşturulmuş bir yedek anahtarı. (2) Bir sabitleme sona erme tarihi belirleyin ve bu tarihten önce uygulama güncellemeleri yayımlayın. (3) Uygulamayı zorunlu kılmadan önce yalnızca raporlama kipini kullanarak sabitleme başarısızlıklarını izleyin. (4) Sabitleme yenileme olayları için acil uygulama güncelleme hattını (hızlandırılmış inceleme) hazır tutun. (5) Yaprak sertifika yenilemelerine uygulama güncellemesi gerekmeden izin vermek için sabitlemeyi yaprak sertifika düzeyinde değil, ara CA düzeyinde yapın.

Electron, Qt veya yerel kodla yazılmış masaüstü uygulamaları, TLS yığını API'lerini kullanarak sabitleme uygulayabilir. Electron uygulamaları, özel doğrulama uygulamak için app.on("certificate-error") olayını ve session.setCertificateVerifyProc() işlevini kullanır. Qt ağ kodu, özel bir doğrulama geri çağırmasıyla QSslSocket kullanır. .NET uygulamaları ServicePointManager.ServerCertificateValidationCallback kullanır. Yerel Windows uygulamaları, elle sertifika incelemesi için WinHTTP kullanır. Masaüstü uygulamaları ek zorluklarla karşılaşır: kurumsal vekiller üzerinden işletim sistemi düzeyinde TLS incelemesi yaygındır ve kullanıcılar vekil işlevlerinin çalışmasını bekleyebilir; bu nedenle sabitlemenin yalnızca belirli uç noktalara uygulanıp uygulanmayacağı konusunda bir ilke kararı gerekir.

Sertifika sabitleme, otomatik sınamayı ve CI/CD dağıtım hatlarını karmaşıklaştırır. Hazırlama sunucularına gerçek HTTPS çağrıları yapan tümleştirme sınamaları, SPKI karmaları bir sınama yapılandırmasında sabitlenmiş sınama sertifikalarını kullanmalıdır. Yaklaşımlar şunlardır: (1) Derleme varyantları — hata ayıklama/hazırlama derlemesi hazırlama sunucusu sabitlemelerini, yayımlama derlemesi ise üretim sabitlemelerini içerir. (2) Ağ Güvenliği Yapılandırması geçersiz kılmaları — Android yalnızca hata ayıklamaya yönelik sabitleme yapılandırmasına izin verir. (3) Sahte sunucu — TLS'den önce HTTP istemcisi katmanında araya girerek sabitlemeyi tamamen devre dışı bırakır. (4) CI için kendinden imzalı CA — kökü yalnızca sınama derlemelerinde güvenilen bir CI CA'sından sınama sertifikaları yayımlamak. Üretimde sabitlemesi devre dışı bırakılmış bir derlemeyi asla yayımlamayın.

Sertifika sabitlemeleri genellikle RSA veya EC genel anahtarlarının karmalarıdır. Kuantum sonrası geçiş başladığında sunucular ML-DSA (CRYSTALS-Dilithium) veya hibrit anahtarlara geçecektir. Sabitlenmiş SPKI karmaları, anahtar türü ve kodlaması değişeceği için değişir. Yaprak sertifikaları veya genel anahtarları sabitleyen uygulamaların eşgüdümlü güncellemelere ihtiyacı olacaktır: (1) Sunucu geçişinden önce, kuantum sonrası SPKI karmasını yedek sabitleme olarak içeren yeni bir uygulama sürümü yayımlayın. (2) Sunucu geçişini tamamlayın. (3) Eski klasik sabitlemeyi kaldıran bir güncelleme yayımlayın. Geçiş aralığı dikkatli bir eşgüdüm gerektirir. Ara veya kök CA'ları sabitleyen uygulamalar bundan daha az etkilenir; yalnızca CA'nın anahtarı değişir ve bu değişiklik, yaprak sertifikalardaki değişikliklerle mutlaka aynı zaman çizelgesinde gerçekleşmez.

SubjectPublicKeyInfo (SPKI) karmasını sabitlemek, sertifikanın tamamını sabitlemeye neden tercih edilir?

Sertifika sabitleme, TLS güvenini belirli bir sertifika veya açık anahtarla sınırlandırarak CA'nın ele geçirilmesine ve MITM saldırılarına karşı koruma sağlar. SPKI karma sabitlemesi (SubjectPublicKeyInfo'nun SHA-256 karması), yenilemelere dayanıklılığı nedeniyle sertifikanın tamamını sabitlemeye tercih edilir. Android, Network Security Config XML'ini kullanır; iOS, SecTrust API'leriyle URLSession temsilcisini kullanır; OkHttp, CertificatePinner desteği sunar. Uygulamaya erişiminizi kilitlememek için her zaman bir yedek sabitleme ekleyin. HPKP (tarayıcı HTTP üst bilgisi) kullanımdan kaldırılmıştır. Sabitleme, Frida kancaları ve ROM değişiklikleri kullanılarak aşılabilir. Kuantum sonrası anahtar geçişi, SPKI karmalarını güncellemek için uygulama güncellemelerinin eşgüdümlü biçimde yayımlanmasını gerektirir.