SSL/TLS: asosiy tushunchalar va protokollar dasturlashda

SSL/TLS nima?

SSL (Secure Sockets Layer) va TLS (Transport Layer Security) — tarmoq orqali ma’lumotlarni xavfsiz uzatishni ta’minlovchi kriptografik protokollardir. 1990-yillarda Netscape tomonidan ishlab chiqilgan SSL, POODLE va BEAST zaifliklari tufayli 3.0 versiyasidan keyin eskirgan deb topildi. Uning vorisi TLS 1.0, 1.1, 1.2 va 1.3 versiyalaridan o‘tdi — hozirda faqat TLS 1.2 va TLS 1.3 dolzarb hisoblanadi. Barcha zamonaviy mobil platformalar tarmoq ulanishlari uchun TLSdan foydalanishni talab qiladi, App Store va Google Play esa buni ko‘rib chiqish bosqichida tekshiradi.

Nega TLS mobil ilovalar uchun kerak

TLSsiz ilova va server o‘rtasidagi trafik ochiq matn shaklida uzatiladi — xuddi shu Wi-Fi tarmog‘idagi har bir kishi Wireshark yoki tcpdump orqali loginlar, parollar, tokenlar va foydalanuvchilarning shaxsiy ma’lumotlarini tutib olishi mumkin. TLS barcha uzatiladigan ma’lumotlarni shifrlaydi (transport darajasida shifrlash) va X.509 sertifikatlari zanjiri orqali serverning haqiqiyligini tekshiradi. IETF (2018) ma’lumotlariga ko‘ra, TLS 1.3 faqat zamonaviy AEAD shifrlaridan (AES-GCM, ChaCha20-Poly1305) foydalanadi, RC4 va 3DES kabi eskirgan algoritmlarni istisno qiladi.

HTTPS va TLS

HTTPS (HTTP Secure) — bu TLS ustidagi HTTP. Mobil ilova https:// orqali so‘rov yuborganda, avval server bilan TLS ulanishini o‘rnatadi, so‘ngra HTTP sarlavhalari va so‘rov tanasini shifrlangan kanal orqali uzatadi. HTTPSsiz hech qanday jiddiy API ishlamasligi kerak — bu asosiy xavfsizlik gigiyenasidir. OWASP (2026) ma’lumotlariga ko‘ra, himoyalanmagan ulanishlar mobil ilovalarning top 3 zaifligiga kiradi.

TLS Handshake qanday ishlaydi

TLS Handshake — mijoz va server o‘rtasida xavfsiz ulanishni o‘rnatish jarayoni. Tomonlar protokol versiyasini kelishib oladi, shifrlar to‘plamini (cipher suite) tanlaydi, assimetrik kriptografiya orqali kalitlarni almashadi va sertifikatlarni tekshiradi. TLS 1.2da qo‘l siqish 2 Round Trip Time (2 RTT) talab qiladi: mijoz → server ClientHello bilan, server → mijoz ServerHello va Certificate bilan, so‘ngra Finished xabarlari. TLS 1.3 bu jarayonni 1 RTTgacha qisqartiradi.

TLS 1.2 qo‘l siqishning batafsil bosqichlari

Birinchi bosqich: ClientHello — mijoz qo‘llab-quvvatlanadigan TLS versiyalari, shifrlar to‘plami ro‘yxati va tasodifiy raqamni yuboradi. Server ServerHello bilan javob beradi, versiya va shifrlar to‘plamini tanlaydi, o‘zining X.509 sertifikatini (Certificate) va ServerHelloDone xabarini yuboradi. Mijoz sertifikatni ishonchli sertifikatsiya markazlari (CA) zanjiri orqali tekshiradi, pre-master secret yaratadi, uni sertifikatdagi ochiq kalit bilan shifrlaydi va ClientKeyExchange da serverga yuboradi. Shundan so‘ng, ikkala tomon seans kalitlarini yaratadi va ChangeCipherSpec va Finished xabarlarini almashadi. Shu paytdan boshlab barcha ma’lumotlar simmetrik shifrlanadi.

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

iOSda URLAuthenticationChallengeni URLSessionDelegate orqali qayta ishlash namunasi. Bu metod har bir TLS Handshake vaqtida chaqiriladi va ilovaga server sertifikatini moslashtirilgan holda tekshirish imkonini beradi. Ishlab chiqarish uchun SecTrustEvaluateWithError orqali sertifikat tekshiruvini qo‘shing va oldindan saqlangan iz bilan solishtiring — shundan keyingina useCredential ni chaqiring.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — protokolning 10 yil ichidagi birinchi yirik yangilanishi. Asosiy yaxshilanishlar: qo‘l siqish 1 RTTgacha qisqartirildi (qayta ulanishlar uchun 0 RTT), eskirgan shifrlar to‘plamlari (RSA key exchange, CBC-mode) olib tashlandi, majburiy mukammal oldinga shifrlash (PFS) va signed transcript orqali downgrade hujumlaridan himoya. Qualys SSL Labs (2026) ma’lumotlariga ko‘ra, TLS 1.3 PFS tufayli hatto uzoq muddatli server kaliti buzilgan taqdirda ham himoyani ta’minlaydi.

0-RTT (Zero Round Trip Time) — TLS 1.3 xususiyati bo‘lib, mijozga qayta ulanishda PSK (Pre-Shared Key) orqali ClientHello bilan birga darhol ma’lumot yuborish imkonini beradi. Bu mobil ilovalarda keyingi ekranlarning yuklanishini tezlashtiradi, ayniqsa bir serverga tez-tez so‘rovlar yuborilganda. Biroq, 0-RTT ma’lumotlari replay hujumlaridan himoyalanmagan — ularni tutib olish va qayta yuborish mumkin. 0-RTT dan faqat yon ta’sirlari bo‘lmagan idempotent so‘rovlar (GET, PUT) uchun foydalaning.

iOSda TLS: App Transport Security

App Transport Security (ATS) — iOS 9 dan sukut bo‘yicha yoqilgan, TLS 1.2 yoki undan yuqori HTTPS ulanishlarini talab qiluvchi Apple mexanizmi. ATS barcha HTTP ulanishlarini va TLS 1.2 dan past HTTPSni bloklaydi. Dasturchi Info.plistda NSAppTransportSecurity orqali ma’lum domenlar uchun istisnolar sozlashi mumkin, ammo Apple istisnolarni minimal darajada ushlab turishni va hamma joyda HTTPSdan foydalanishni tavsiya qiladi. ATS talablarini buzish App Store ko‘rib chiqishida ilovaning rad etilishiga sabab bo‘ladi.

<!-- 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.plistda ATS sozlamasi. NSAllowsArbitraryLoads false ga o‘rnatilgan — barcha ulanishlar HTTPSdan foydalanishi shart. cdn.example.com domeni uchun minimal TLS 1.2 versiyasi o‘rnatilgan, NSAllowsLocalNetworking=true mahalliy tarmoq uchun HTTPga ruxsat beradi (dev serverlar uchun foydali). Apple NSExceptionDomainsiz NSAllowsArbitraryLoadsni yoqmaslikni qat‘iy tavsiya qiladi — bu istisno bo‘lishi kerak, umumiy qoida emas.

Androidda TLS: Network Security Config

Network Security Config — Java/Kotlin kodini o‘zgartirmasdan HTTPS va TLSni sozlash uchun Android mexanizmi. Konfiguratsiya network_security_config.xml XML faylida aniqlanadi va AndroidManifestda android:networkSecurityConfig atributi orqali ulanadi. Ishonchli sertifikatlarni (user va system CA), Certificate Pinningni, cleartext HTTPni o‘chirishni, debug bekor qilishlarni va trafik yo‘naltirishni sozlashni qo‘llab-quvvatlaydi.

<!-- 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 uchun Network Security Config. Base-config cleartext trafikini taqiqlaydi va faqat tizim CA sertifikatlariga ishonadi (foydalanuvchi sertifikatlarisiz — foydalanuvchi tomonidan MitM sertifikatlarini o‘rnatishdan himoya). api.example.com uchun Domain-config sertifikatning SHA-256 izi bilan pin-setni o‘z ichiga oladi. Agar server sertifikati belgilangan muddatdan oldin o‘zgarsa, ulanish rad etiladi — bu qattiq Certificate Pinning shaklidir.

Certificate Pinning va xavfsizlik

Certificate Pinning — ilova kodida server sertifikati yoki ochiq kalitini fiksatsiyalash texnikasi. Har bir TLS Handshake vaqtida mijoz server sertifikatini oldindan saqlangan iz bilan (SHA-256 hash) solishtiradi. Hujumchi ishonchli CA sertifikatini olgan yoki sertifikatsiya markazini buzgan taqdirda ham, MitM hujumini amalga oshira olmaydi — ilova CA zanjirini emas, balki aniq izni tekshiradi. Bu, ayniqsa, moliyaviy ilovalar va maxfiy ma’lumotlarga ega ilovalar uchun muhimdir.

Pinning xavflari va alternativlari

Certificate Pinning ehtiyotkorlikni talab qiladi: serverda sertifikat o‘zgarganda, ilovaning barcha eski versiyalari ulana olmaydi. Bir nechta zaxira izlarni saqlash (asosiy + zaxira), pin-setning amal qilish muddatini belgilash va standart CA tekshiruvi orqali fallback mexanizmini amalga oshirish tavsiya etiladi. Alternativ — Trust On First Use (TOFU), bunda ilova birinchi ulanishda sertifikatni eslab qoladi va u o‘zgarganda foydalanuvchini ogohlantiradi. OWASP (2026) ma’lumotlariga ko‘ra, Certificate Pinningning yo‘qligi mobil ilovalarning top 3 zaifligiga kiradi (M3: Insecure Communication).

Alamofireda Pinningni amalga oshirish

Alamofire 5+ da Certificate Pinning ServerTrustManager bilan PinnedCertificatesTrustEvaluator (to‘liq sertifikatni tekshirish) yoki PublicKeysTrustEvaluator (faqat ochiq kalit) orqali sozlanadi. Ochiq kalit afzalroq — xuddi shu CA da sertifikat yangilanganda o‘zgarmaydi. [host: evaluator] lug‘ati bilan ServerTrustManager yarating, uni Sessionga uzating va himoyalangan APIlarga barcha so‘rovlar uchun foydalaning.