SSL/TLS: əsas anlayışlar və protokollar proqramlaşdırmada

SSL/TLS nədir?

SSL (Secure Sockets Layer) və TLS (Transport Layer Security) — şəbəkə üzərindən təhlükəsiz məlumat ötürülməsini təmin edən kriptoqrafik protokollardır. 1990-cı illərdə Netscape tərəfindən hazırlanmış SSL, POODLE və BEAST zəiflikləri səbəbindən 3.0 versiyasından sonra köhnəlmiş hesab edilir. Onun varisi TLS 1.0, 1.1, 1.2 və 1.3 versiyalarından keçib — hazırda yalnız TLS 1.2 və TLS 1.3 aktual sayılır. Bütün müasir mobil platformalar şəbəkə qoşulmaları üçün TLS istifadəsini tələb edir, App Store və Google Play isə bunu icmal mərhələsində yoxlayır.

TLS mobil tətbiqlərə niyə lazımdır

TLS olmadan tətbiq və server arasında trafik açıq mətnlə ötürülür — eyni Wi-Fi şəbəkəsindəki hər kəs Wireshark və ya tcpdump vasitəsilə giriş məlumatlarını, parolları, tokenləri və istifadəçilərin şəxsi məlumatlarını ələ keçirə bilər. TLS bütün ötürülən məlumatları şifrələyir (nəqliyyat səviyyəsində şifrələmə) və X.509 sertifikatları zənciri vasitəsilə serverin həqiqiliyini yoxlayır. IETF (2018) məlumatlarına görə, TLS 1.3 yalnız müasir AEAD şifrələrindən (AES-GCM, ChaCha20-Poly1305) istifadə edir, RC4 və 3DES kimi köhnəlmiş alqoritmləri istisna edir.

HTTPS və TLS

HTTPS (HTTP Secure) — TLS üzərindən HTTP-dir. Mobil tətbiq https:// ilə sorğu göndərdikdə, əvvəlcə serverlə TLS qoşulması qurur, sonra HTTP başlıqlarını və sorğu gövdəsini artıq şifrələnmiş kanal vasitəsilə ötürür. HTTPS olmadan heç bir ciddi API işləməməlidir — bu əsas təhlükəsizlik gigiyenasıdır. OWASP (2026) məlumatlarına görə, qorunmayan qoşulmalar mobil tətbiqlərin top 3 zəifliyinə daxildir.

TLS Handshake necə işləyir

TLS Handshake — müştəri və server arasında təhlükəsiz qoşulmanın qurulması prosesidir. Tərəflər protokol versiyasını razılaşdırır, şifrələmə dəstini (cipher suite) seçir, asimmetrik kriptoqrafiya vasitəsilə açarları mübadilə edir və sertifikatları yoxlayır. TLS 1.2-də əl sıxma 2 Round Trip Time (2 RTT) tələb edir: müştəri → server ClientHello, server → müştəri ServerHello və Certificate, sonra Finished mesajları. TLS 1.3 bu prosesi 1 RTT-yə qədər qısaldır.

TLS 1.2 əl sıxmasının ətraflı mərhələləri

Birinci mərhələ: ClientHello — müştəri dəstəklənən TLS versiyalarını, şifrələmə dəstlərinin siyahısını və təsadüfi ədədi göndərir. Server ServerHello ilə cavab verir, versiya və şifrələmə dəstini seçir, öz X.509 sertifikatını (Certificate) və ServerHelloDone mesajını göndərir. Müştəri sertifikatı etibarlı sertifikat mərkəzləri (CA) zənciri vasitəsilə yoxlayır, pre-master secret yaradır, onu sertifikatdakı açıq açarla şifrələyir və ClientKeyExchange-də serverə göndərir. Bundan sonra hər iki tərəf seans açarlarını yaradır və ChangeCipherSpec və Finished mesajlarını mübadilə edir. Bu andan etibarən bütün məlumatlar simmetrik şifrələnir.

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))
}

iOS-da URLAuthenticationChallenge-in URLSessionDelegate vasitəsilə işlənməsi nümunəsi. Bu metod hər TLS Handshake zamanı çağırılır və tətbiqə server sertifikatını fərdi qaydada yoxlamağa imkan verir. İstehsal üçün SecTrustEvaluateWithError vasitəsilə sertifikat yoxlaması əlavə edin və əvvəlcədən saxlanılmış iz ilə müqayisə edin — yalnız bundan sonra useCredential çağırın.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — protokolun 10 il ərzində ilk böyük yenilənməsidir. Əsas təkmilləşdirmələr: əl sıxma 1 RTT-yə qədər qısaldılıb (təkrar qoşulmalar üçün 0 RTT), köhnəlmiş şifrələmə dəstləri (RSA key exchange, CBC-mode) silinib, məcburi mükəmməl irəli şifrələmə (PFS) və signed transcript vasitəsilə downgrade hücumlarından qorunma. Qualys SSL Labs (2026) məlumatlarına görə, TLS 1.3 PFS sayəsində hətta uzunmüddətli server açarının kompromitasiyası zamanı belə qoruma təmin edir.

0-RTT (Zero Round Trip Time) — TLS 1.3-ün xüsusiyyəti, müştəriyə təkrar qoşulma zamanı PSK (Pre-Shared Key) vasitəsilə ClientHello ilə birlikdə dərhal məlumat göndərməyə imkan verir. Bu, mobil tətbiqlərdə növbəti ekranların yüklənməsini sürətləndirir, xüsusən eyni serverə tez-tez sorğular zamanı. Lakin 0-RTT məlumatları replay hücumlarından qorunmur — onlar ələ keçirilə və təkrar göndərilə bilər. 0-RTT-dən yalnız yan təsirləri olmayan idempotent sorğular (GET, PUT) üçün istifadə edin.

iOS-da TLS: App Transport Security

App Transport Security (ATS) — iOS 9-dan etibarən defolt olaraq aktiv olan, TLS 1.2 və ya daha yüksək HTTPS qoşulmalarını tələb edən Apple mexanizmidir. ATS bütün HTTP qoşulmalarını və TLS 1.2-dən aşağı HTTPS-i bloklayır. Tərtibatçı Info.plist-də NSAppTransportSecurity vasitəsilə müəyyən domenlər üçün istisnalar konfiqurasiya edə bilər, lakin Apple istisnaları minimuma endirməyi və hər yerdə HTTPS istifadə etməyi tövsiyə edir. ATS tələblərinin pozulması App Store icmalında tətbiqin rədd edilməsinə səbəb olur.

<!-- 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-də ATS konfiqurasiyası. NSAllowsArbitraryLoads false olaraq təyin edilib — bütün qoşulmalar HTTPS istifadə etməlidir. cdn.example.com domeni üçün minimum TLS 1.2 versiyası təyin edilib, NSAllowsLocalNetworking=true lokal şəbəkə üçün HTTP-yə icazə verir (dev serverlər üçün faydalıdır). Apple NSExceptionDomains olmadan NSAllowsArbitraryLoads-ı aktivləşdirməməyi qətiliklə tövsiyə edir — bu istisna olmalıdır, ümumi qayda deyil.

Android-də TLS: Network Security Config

Network Security Config — Java/Kotlin kodunu dəyişmədən HTTPS və TLS konfiqurasiyası üçün Android mexanizmidir. Konfiqurasiya network_security_config.xml XML faylında təyin edilir və AndroidManifest-də android:networkSecurityConfig atributu vasitəsilə qoşulur. Etibarlı sertifikatların (user və system CA), Certificate Pinning, cleartext HTTP-nin söndürülməsi, debug üstün yazmaları və trafik yönləndirilməsinin konfiqurasiyasını dəstəkləyir.

<!-- 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 üçün Network Security Config. Base-config cleartext trafikini qadağan edir və yalnız sistem CA sertifikatlarına etibar edir (istifadəçi sertifikatları olmadan — istifadəçi tərəfindən MitM sertifikatlarının quraşdırılmasından qorunma). api.example.com üçün Domain-config sertifikatın SHA-256 izi ilə pin-set ehtiva edir. Server sertifikatı göstərilən expiration tarixindən əvvəl dəyişərsə, qoşulma rədd ediləcək — bu sərt Certificate Pinning formasıdır.

Certificate Pinning və təhlükəsizlik

Certificate Pinning — tətbiq kodunda serverin sertifikatının və ya açıq açarının fiksasiyası texnikasıdır. Hər TLS Handshake zamanı müştəri server sertifikatını əvvəlcədən saxlanılmış izlə (SHA-256 hash) müqayisə edir. Hücumçu etibarlı CA sertifikatı alsa və ya sertifikat mərkəzini kompromitasiya etsə belə, MitM hücumu həyata keçirə bilməz — tətbiq CA zəncirini deyil, konkret izi yoxlayır. Bu, xüsusilə maliyyə tətbiqləri və həssas məlumatları olan tətbiqlər üçün vacibdir.

Pinning riskləri və alternativləri

Certificate Pinning ehtiyatlılıq tələb edir: serverdə sertifikat dəyişdikdə, tətbiqin bütün köhnə versiyaları qoşula bilməyəcək. Bir neçə ehtiyat iz saxlamaq (əsas + ehtiyat), pin-set-in bitmə tarixini göstərmək və standart CA yoxlaması vasitəsilə fallback mexanizmi tətbiq etmək tövsiyə olunur. Alternativ — Trust On First Use (TOFU), tətbiqin ilk qoşulmada sertifikatı yadda saxlaması və dəyişdikdə istifadəçini xəbərdar etməsidir. OWASP (2026) məlumatlarına görə, Certificate Pinning-in olmaması mobil tətbiqlərin top 3 zəifliyinə daxildir (M3: Insecure Communication).

Alamofire-də Pinning-in tətbiqi

Alamofire 5+-da Certificate Pinning ServerTrustManager ilə PinnedCertificatesTrustEvaluator (tam sertifikatın yoxlanması) və ya PublicKeysTrustEvaluator (yalnız açıq açar) vasitəsilə konfiqurasiya edilir. Açıq açar üstünlük təşkil edir — eyni CA-da sertifikat yenilənərkən dəyişmir. [host: evaluator] lüğəti ilə ServerTrustManager yaradın, onu Session-a ötürün və qorunan API-lərə bütün sorğular üçün istifadə edin.