SSL/TLS: geliştirmede temel kavramlar ve protokoller

SSL/TLS nedir?

SSL (Güvenli Soket Katmanı) ve TLS (Taşıma Katmanı Güvenliği), ağ üzerinden güvenli veri iletimini sağlayan kriptografik protokollerdir. 1990'larda Netscape tarafından geliştirilen SSL, POODLE ve BEAST güvenlik açıkları nedeniyle sürüm 3.0'dan sonra eski olarak kabul edilir. Halefi TLS, 1.0, 1.1, 1.2 ve 1.3 sürümlerinden geçmiştir — yalnızca TLS 1.2 ve TLS 1.3 güncel kabul edilir. Tüm modern mobil platformlar ağ bağlantıları için TLS gerektirir ve App Store ile Google Play inceleme sırasında bunu kontrol eder.

Mobil uygulamalar için neden TLS

TLS olmadan, uygulama ve sunucu arasındaki trafik düz metin olarak iletilir — aynı Wi-Fi ağındaki herhangi biri Wireshark veya tcpdump kullanarak giriş bilgilerini, parolaları, tokenları ve kullanıcıların kişisel verilerini ele geçirebilir. TLS, iletilen tüm verileri şifreler (taşıma katmanı şifrelemesi) ve X.509 sertifikaları zinciri aracılığıyla sunucunun kimliğini doğrular. IETF (2018)'e göre, TLS 1.3 yalnızca modern AEAD şifrelerini (AES-GCM, ChaCha20-Poly1305) kullanır ve RC4 ile 3DES gibi eski algoritmaları hariç tutar.

HTTPS ve TLS

HTTPS (HTTP Secure), TLS üzerinden HTTP'dir. Bir mobil uygulama https:// ile istek yaptığında, önce sunucuyla TLS bağlantısı kurar, ardından şifrelenmiş kanal üzerinden HTTP başlıklarını ve istek gövdesini iletir. HTTPS olmadan hiçbir ciddi API çalışmamalıdır — bu temel güvenlik hijyenidir. OWASP (2026)'ya göre, güvenli olmayan bağlantılar mobil uygulamaların ilk 3 güvenlik açığı arasındadır.

TLS El Sıkışma nasıl çalışır

TLS El Sıkışma, istemci ve sunucu arasında güvenli bir bağlantı kurma sürecidir. Taraflar protokol sürümünü müzakere eder, bir şifre takımı (cipher suite) seçer, asimetrik kriptografi aracılığıyla anahtarları değiş tokuş eder ve sertifikaları doğrular. TLS 1.2'de, el sıkışma 2 Gidiş-Dönüş Süresi (2 RTT) gerektirir: istemci → sunucu ClientHello ile, sunucu → istemci ServerHello ve Certificate ile, ardından son Finished mesajları. TLS 1.3 bu süreci 1 RTT'ye düşürür.

TLS 1.2 el sıkışmasının ayrıntılı aşamaları

İlk aşama: ClientHello — istemci desteklenen TLS sürümlerini, şifre takımlarının bir listesini ve rastgele bir sayı gönderir. Sunucu ServerHello ile yanıt verir, bir sürüm ve şifre takımı seçer, X.509 sertifikasını (Certificate) ve ServerHelloDone mesajını gönderir. İstemci, güvenilir sertifika yetkilileri (CA) zinciri aracılığıyla sertifikayı doğrular, bir ön-master sırrı (pre-master secret) oluşturur, bunu sertifikadaki açık anahtarla şifreler ve ClientKeyExchange'de sunucuya gönderir. Bundan sonra, her iki taraf oturum anahtarları oluşturur ve ChangeCipherSpec ile Finished mesajlarını değiş tokuş eder. Bu noktadan itibaren tüm veriler simetrik olarak şifrelenir.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

URLSessionDelegate aracılığıyla iOS'ta URLAuthenticationChallenge işleme örneği. Bu yöntem, her TLS El Sıkışma sırasında çağrılır ve uygulamanın özel sunucu sertifikası doğrulaması yapmasına olanak tanır. Üretim kullanımı için, SecTrustEvaluateWithError aracılığıyla sertifika doğrulaması ekleyin ve önceden kaydedilmiş bir parmak iziyle karşılaştırın — ancak bundan sonra useCredential'ı çağırın.

TLS 1.2 ve TLS 1.3

TLS 1.3 (RFC 8446, 2018) 10 yıl içindeki ilk büyük protokol güncellemesidir. Başlıca iyileştirmeler: el sıkışmanın 1 RTT'ye düşürülmesi (tekrarlanan bağlantılar için 0 RTT), eski şifre takımlarının kaldırılması (RSA anahtar değişimi, CBC modu), zorunlu Perfect Forward Secrecy (PFS) ve imzalı transkript (signed transcript) aracılığıyla düşürme saldırılarına karşı koruma. Qualys SSL Labs (2026)'ya göre, TLS 1.3, PFS sayesinde uzun vadeli sunucu anahtarı tehlikeye girse bile koruma sağlar.

0-RTT (Sıfır Gidiş-Dönüş Süresi), TLS 1.3'ün bir özelliğidir ve istemcinin PSK (Önceden Paylaşılmış Anahtar) aracılığıyla tekrarlanan bir bağlantı sırasında ClientHello ile birlikte hemen veri göndermesine olanak tanır. Bu, özellikle aynı sunucuya sık yapılan isteklerde mobil uygulamalarda sonraki ekranların yüklenmesini hızlandırır. Ancak, 0-RTT verileri tekrar saldırılarına (replay attacks) karşı korunmaz — ele geçirilebilir ve yeniden gönderilebilir. 0-RTT'yi yalnızca yan etkisi olmayan idempotent istekler (GET, PUT) için kullanın.

iOS'ta TLS: App Transport Security

App Transport Security (ATS), TLS 1.2 veya üzeri ile HTTPS bağlantıları gerektiren Apple mekanizmasıdır ve iOS 9'dan beri varsayılan olarak etkindir. ATS, tüm HTTP bağlantılarını ve TLS 1.2 altındaki HTTPS'yi engeller. Geliştirici, belirli alan adları için NSAppTransportSecurity aracılığıyla Info.plist'te istisnalar yapılandırabilir, ancak Apple istisnaları en aza indirmeyi ve her yerde HTTPS kullanmayı önerir. ATS gereksinimlerinin ihlali, App Store incelemesinde uygulamanın reddedilme nedenidir.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Info.plist'te ATS yapılandırması. NSAllowsArbitraryLoads false olarak ayarlanmıştır — tüm bağlantılar HTTPS kullanmalıdır. cdn.example.com alan adı için minimum TLS sürümü 1.2 belirtilmiştir, NSAllowsLocalNetworking=true yerel ağ için HTTP'ye izin verir (geliştirme sunucuları için kullanışlıdır). Apple, NSExceptionDomains olmadan NSAllowsArbitraryLoads'u etkinleştirmemeyi şiddetle önerir — bu genel bir kural değil, bir istisna olmalıdır.

Android'de TLS: Network Security Config

Network Security Config, Java/Kotlin kodunu değiştirmeden HTTPS ve TLS'yi yapılandırmak için Android mekanizmasıdır. Yapılandırma network_security_config.xml dosyasında belirtilir ve android:networkSecurityConfig özniteliği aracılığıyla AndroidManifest'e bağlanır. Güvenilir sertifikaların (kullanıcı ve sistem CA), Certificate Pinning'in, düz metin HTTP'nin devre dışı bırakılmasının, hata ayıklama geçersiz kılmalarının ve trafik yönlendirmesinin yapılandırılmasını destekler.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Android için Network Security Config. Base-config, düz metin trafiğini engeller ve yalnızca sistem CA sertifikalarına güvenir (kullanıcı sertifikaları yok — kullanıcılar tarafından MitM sertifikası kurulumuna karşı koruma). api.example.com için domain-config, SHA-256 sertifika parmak izine sahip bir pin-set içerir. Sunucu sertifikası belirtilen son kullanma tarihinden önce değişirse, bağlantı reddedilecektir — bu, Certificate Pinning'in katı bir şeklidir.

Certificate Pinning ve güvenlik

Certificate Pinning, uygulama kodunda sunucunun sertifikasını veya açık anahtarını sabitleme tekniğidir. Her TLS El Sıkışma sırasında, istemci sunucu sertifikasını önceden kaydedilmiş bir parmak iziyle (SHA-256 karması) karşılaştırır. Bir saldırgan güvenilir bir CA sertifikası elde etse veya sertifika yetkilisini tehlikeye atsa bile MitM saldırısı gerçekleştiremez — uygulama CA zincirini değil, belirli parmak izini kontrol eder. Bu, özellikle finansal uygulamalar ve hassas verileri işleyen uygulamalar için önemlidir.

Pinning'in riskleri ve alternatifleri

Certificate Pinning dikkat gerektirir: sunucu sertifikası değiştiğinde, uygulamanın tüm eski sürümleri bağlantıyı keser. Birden fazla yedek parmak izi (birincil + yedek) saklanması, pin-set son kullanma tarihi belirtilmesi ve standart CA doğrulaması yoluyla bir yedek mekanizma uygulanması önerilir. Bir alternatif, uygulamanın ilk bağlantıda sertifikayı hatırladığı ve değiştiğinde kullanıcıyı uyardığı Trust On First Use (TOFU)'dur. OWASP (2026)'ya göre, Certificate Pinning'in yokluğu mobil uygulamaların ilk 3 güvenlik açığı (M3: Güvensiz İletişim) arasındadır.

Alamofire'da Pinning uygulaması

Alamofire 5+'da, Certificate Pinning ServerTrustManager ile PinnedCertificatesTrustEvaluator (tam sertifika kontrolü) veya PublicKeysTrustEvaluator (yalnızca açık anahtar) aracılığıyla yapılandırılır. Açık anahtar tercih edilir — aynı CA ile sertifika yenilendiğinde değişmez. [host: evaluator] sözlüğüyle bir ServerTrustManager oluşturun, bunu Session'a aktarın ve korumalı API'lere yapılan tüm istekler için kullanın.