SSL/TLS — bu nədir, protokollar və şifrələmənin iş prinsipi

SSL/TLS nədir?

SSL (Secure Sockets Layer) — 1995-ci ildə Netscape şirkəti tərəfindən veb trafikini qorumaq üçün hazırlanmış protokol. SSL 1.0-ın ilk versiyası heç vaxt dərc olunmayıb, SSL 2.0 (1995) və SSL 3.0 (1996) 2000-ci illərin əvvəllərinə qədər istifadə edilmiş, lakin kritik zəifliklərə malik idi. SSL-in yerinə IETF tərəfindən standartlaşdırılmış təkmilləşdirilmiş versiya olan TLS (Transport Layer Security) gəldi. TLS 1.0 (1999) SSL 3.0-a əsaslanırdı, sonrakı versiyalar TLS 1.1 (2006), TLS 1.2 (2008) və TLS 1.3 (2018) isə tədricən orijinal arxitekturadan uzaqlaşaraq yeni şifrələmə alqoritmləri əlavə edir və zəiflikləri aradan qaldırırdı. Bu gün SSL köhnəlmiş hesab olunur və bütün müasir sistemlər TLS-dən istifadə edir, baxmayaraq ki, ətalət səbəbindən hər iki protokol tez-tez birlikdə SSL/TLS kimi xatırlanır.

Protokolun yaranma tarixi

SSL/TLS-in tarixi erkən internetdə təhlükəsiz məlumat ötürülməsi ehtiyacından başladı. 1994-cü ildə Netscape şirkəti öz Navigator brauzeri üçün SSL 1.0-ı hazırladı, lakin ciddi təhlükəsizlik problemləri səbəbindən protokol heç vaxt dərc olunmadı. SSL 2.0 1995-ci ildə buraxıldı və praktikada istifadə edildi, lakin çoxsaylı zəifliklərə malik idi: Man-in-the-Middle hücumlarından qorunmanın olmaması, zəif şifrələmə alqoritmləri və truncation hücumlarına qarşı həssaslıq. SSL 3.0 (1996) problemlərin əksəriyyətini həll etdi, lakin 2014-cü ilə qədər orada POODLE zəifliyi aşkar edildi, bundan sonra IETF rəsmi olaraq SSL-in bütün versiyalarını köhnəlmiş elan etdi. TLS 1.0–1.3 ardıcıl olaraq kriptoqrafik gücü, performansı və məxfiliyi yaxşılaşdırdı, TLS 1.3 isə handshake-i iki round-trip-dən birə endirdi ki, bu da qeyri-sabit bağlantısı olan mobil tətbiqlər üçün kritik əhəmiyyət daşıyır.

SSL/TLS Handshake necə işləyir

Handshake — müştəri və server arasında təhlükəsiz bağlantının qurulması prosesidir. Bu, tərəflərin protokol versiyasını razılaşdırdığı, şifrələmə alqoritmlərini seçdiyi, açarları mübadilə etdiyi və bir-birini autentifikasiya etdiyi bir neçə ardıcıl addımdan ibarətdir. TLS 1.3-də handshake cəmi bir şəbəkə qarşılıqlı əlaqəsi (1-RTT) tələb edir, TLS 1.2-də isə iki (2-RTT) tələb olunurdu.

İlk addımda müştəri ClientHello — dəstəklənən TLS versiyalarının siyahısı, şifrər dəstləri (cipher suites) və təsadüfi ədəd ehtiva edən mesaj göndərir. Server seçilmiş versiya və şifrlə, öz X.509 sertifikatı və rəqəmsal imzası ilə ServerHello cavabını göndərir. Müştəri sertifikatı sertifikat mərkəzləri (CA) zənciri vasitəsilə yoxlayır, sessiya açarı yaradır və onu serverin sertifikatındakı açıq açarı ilə şifrələnmiş şəkildə göndərir. Server təsdiqlədikdən sonra təhlükəsiz məlumat ötürülməsi başlayır. Bütün handshake müasir cihazlarda 1–3 millisaniyə ərzində yerinə yetirilir ki, bu da onu istifadəçi üçün görünməz edir.

X.509 sertifikatları və etibar zənciri

TLS autentifikasiyası-nın əsası X.509 formatında sertifikatlar üzərində qurulmuş açıq açarlar infrastrukturudur (PKI). Hər bir sertifikatda: domen adı (Common Name və ya Subject Alternative Name), serverin açıq açarı, verənin adı (Certificate Authority), etibarlılıq müddəti və CA-nın rəqəmsal imzası var. Müştəri serverin sertifikatını etibar zənciri vasitəsilə yoxlayır: server sertifikatından əməliyyat sisteminə daxil edilmiş kök CA-ya qədər. Android cihazlarında kök sertifikatlar Google Play Services vasitəsilə yenilənən sistem anbarında saxlanılır; iOS-da — iOS Updates vasitəsilə. Zəncirin hər hansı bir halqası pozulduqda (vaxtı keçmiş sertifikat, domen uyğunsuzluğu, naməlum CA) müştəri bağlantını kəsir. Öz-özünə imzalanmış sertifikatlar (inkişaf mərhələsində istifadə olunur) üçün açıq şəkildə etibar tələb olunur — Android-də Network Security Config, iOS-da Info.plist-də NSExceptionDomains vasitəsilə. Sertifikat zəncirinin validasiya prosesi həmçinin CRL (Certificate Revocation List) və ya OCSP (Online Certificate Status Protocol) vasitəsilə ləğv statusunun yoxlanılmasını əhatə edir, baxmayaraq ki, mobil cihazlarda OCSP sorğuları bağlantını sürətləndirmək üçün tez-tez buraxılır — bu, arxitektorların nəzərə almalı olduğu təhlükəsizlik və performans arasında kompromisdir.

SSL vs TLS: əsas fərqlər

SSL və TLS terminləri tez-tez sinonim kimi istifadə edilsə də, onlar arasında mobil tətbiqlərin təhlükəsizliyinə və performansına təsir edən prinsipial texniki fərqlər var.

TLS 1.3-ün sələflərindən əsas fərqi — ECDHE protokolu vasitəsilə Perfect Forward Secrecy (PFS)-nin məcburi istifadəsidir. Bu o deməkdir ki, hətta hücumçu serverin şəxsi açarına çıxış əldə etsə belə, əvvəllər ələ keçirilmiş trafiki deşifrə edə bilməyəcək. Serverin sındırılmasının real təhlükə olduğu mobil tətbiqlər üçün PFS ilə TLS 1.3 məcburi təhlükəsizlik tələbidir.

Köhnə versiyaların məlum zəiflikləri

SSL və TLS-in köhnəlmiş versiyaları onları istehsal mühitində istifadə üçün yararsız edən sənədləşdirilmiş zəifliklərə malikdir. POODLE (CVE-2014-3566) padding oracle vasitəsilə SSL 3.0-a hücum edərək sessiya kukisini 256 sorğu ilə deşifrə etməyə imkan verir. BEAST (CVE-2011-3389) proqnozlaşdırıla bilən IV vasitəsilə TLS 1.0-ın CBC rejimində zəifliyindən istifadə edir. Heartbleed (CVE-2014-0160) — protokol zəifliyi deyil, OpenSSL tətbiqində server yaddaşını oxumağa imkan verən xətadır: Netcraft-a görə, 2014-cü ildə 500 mindən çox server həssas idi. Android 10 (API 29) və iOS 13-dən başlayaraq, qeyd olunan bütün protokollar sistem səviyyəsində söndürülüb. Buna baxmayaraq, tərtibatçılar tətbiqi işə salmazdan əvvəl SSL Labs Test (qualys.com) vasitəsilə server konfiqurasiyasını yoxlamalıdırlar ki, köhnəlmiş cipher suites-lər olmasın və TLS 1.3 dəstəklənsin.

SSL/TLS mobil tətbiqlərdə məlumatları necə qoruyur

Mobil tətbiqlərdə TLS məlumatları üç səviyyədə qoruyur: məzmunun şifrələməsi (serverdən başqa heç kim məlumatları oxuya bilməz), bütövlüyün yoxlanılması (məlumatlar yolda dəyişdirilə bilməz) və serverin autentifikasiyası (müştəri məhz düzgün serverə qoşulduğuna əmin olur). Autentifikasiya xüsusilə kritikdir: onsuz hücumçu DNS-spoofing və ya saxta Wi-Fi giriş nöqtəsi vasitəsilə serveri əvəz edə bilər.

Google Play Protect (2024) tədqiqatına görə, Android tətbiqlərinin 76%-i sertifikat yoxlaması ilə TLS-dən düzgün istifadə edir. Qalan 24%-i səhvlərə yol verir: test üçün sertifikat yoxlamasını söndürür (və istehsalda yandırmağı unudur), validasiyasız öz-özünə imzalanmış sertifikatlardan istifadə edir və ya köhnəlmiş SSL 3.0 və TLS 1.0 protokollarına icazə verir. Apple App Transport Security (ATS) iOS-da 2017-ci ildən etibarən minimum TLS 1.2 tələb edir, iOS 15-dən isə bütün şəbəkə sorğuları üçün standart olaraq TLS 1.3 istifadə edir. Əlavə qorunma üçün Certificate Pinning — serverin konkret sertifikatına bağlamanın tətbiqi də tövsiyə olunur.

SSL/TLS-in mobil tətbiqlərdə tətbiqi

Şəbəkə ilə iş üçün ən məşhur kitabxanalardan biri olan OkHttp istifadə edərək Android-də təhlükəsiz HTTPS bağlantısının qurulması nümunəsinə baxaq. Düzgün konfiqurasiya TLS 1.3-ün məcburi istifadəsini və sertifikatların yoxlanılmasını əhatə edir.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

Bu nümunədə dəstəklənən TLS versiyalarını yalnız 1.3 və 1.2 protokolları ilə məhdudlaşdırırıq, köhnəlmiş TLS 1.0/1.1-i istisna edirik. Cipher suites-lər AEAD rejimi və məcburi Perfect Forward Secrecy ilə müasir alqoritmlərdən seçilir. HostnameVerifier host adının sertifikata uyğunluğunu yoxlayır. iOS üçün analoji konfiqurasiya tlsMinimumSupportedProtocolVersion parametri ilə URLSession konfiqurasiyası vasitəsilə həyata keçirilir, burada .TLSv13 göstərilir. Əlavə olaraq iOS-da versiyaların yuxarı həddini məhdudlaşdırmaq üçün tlsMaximumSupportedProtocolVersion təyin edilə bilər — bu, hələ TLS 1.3-ə keçməmiş köhnə serverlərlə uyğunluq üçün faydalıdır. Belə konfiqurasiya mobil tətbiqdə məlumat ötürülməsi zamanı maksimum təhlükəsizlik səviyyəsini təmin edir.