HTTP/HTTPS: bu nədir, məlumat ötürmə protokolları və TLS şifrələmə

HTTP və HTTPS nədir?

HTTP (HyperText Transfer Protocol) — World Wide Web-də hipermətn sənədlərini və digər məlumatları ötürmək üçün nəzərdə tutulmuş OSI modelinin tətbiq qatı protokoludur. 1989-cu ildə Tim Berners-Li tərəfindən hazırlanmış HTTP bir neçə versiya keçmişdir: HTTP/0.9 (yalnız GET sorğuları və HTML cavabları) müasir HTTP/2 və HTTP/3-ə qədər. Protokol sorğu-cavab sxemi ilə işləyir: müştəri serverə sorğu göndərir, server onu emal edir və cavab qaytarır.

HTTPS (HTTP Secure) — TLS (Transport Layer Security) vasitəsilə şifrələmə səviyyəsi əlavə edən HTTP protokolunun genişləndirilməsidir. HTTPS ayrıca bir protokol deyil — bu HTTP və TLS-in kombinasiyasıdır. HTTPS vasitəsilə ötürülən məlumatlar müştəri tərəfində şifrələnir və serverdə deşifrə olunur, bu da onları ələ keçirmək və saxtalaşdırmaq üçün əlçatmaz edir. HTTPS həmçinin SSL/TLS sertifikatları vasitəsilə server autentifikasiyasını təmin edir, müştərinin həqiqi serverə qoşulduğuna zəmanət verir.

HTTP və HTTPS arasındakı əsas fərq təhlükəsizlikdir. HTTP məlumatları açıq formada ötürür: müştəri ilə server arasındakı şəbəkənin istənilən qovşağı sorğu və ya cavabın məzmununu oxuya bilər. HTTPS bütün məzmunu, o cümlədən URL, başlıqlar və sorğu gövdəsini şifrələyir, yalnız serverin IP ünvanı və qoşulma portunu görünən qoyur. İctimai Wi-Fi şəbəkələri vasitəsilə işləyən mobil tətbiqlər üçün HTTPS məcburi təhlükəsizlik tələbidir.

HTTP necə işləyir

HTTP — TCP/IP üzərində işləyən vəziyyətsiz (stateless) protokoludur. Müştəri serverlə TCP əlaqəsi qurur (adətən HTTP üçün port 80 və ya HTTPS üçün port 443), HTTP sorğusu göndərir, HTTP cavabı alır və əlaqəni bağlayır (HTTP/1.1-də əlaqə təkrar istifadə oluna bilər). Müştəri və server arasında hər bir qarşılıqlı əlaqə sorğu və cavabdan ibarətdir. Vəziyyətsiz olmaq o deməkdir ki, server müştərinin əvvəlki sorğuları haqqında məlumat saxlamır — hər sorğu müstəqil şəkildə emal olunur.

HTTP qarşılıqlı əlaqə prosesi aşağıdakı addımları əhatə edir:

• DNS həlli — brauzer və ya müştəri domen adını DNS vasitəsilə IP ünvanına çevirir
• TCP əl sıxması — üç mərhələli əl sıxma (SYN, SYN-ACK, ACK) vasitəsilə TCP əlaqəsi qurulur
• TLS əl sıxması — HTTPS üçün əlavə olaraq şifrələnmiş əlaqə qurulur (sertifikat və açarların mübadiləsi)
• HTTP sorğusu — müştəri metod, URL, başlıqlar və isteğe bağlı olaraq sorğu gövdəsini göndərir
• HTTP cavabı — server status kodu, başlıqlar və cavab gövdəsini qaytarır

HTTP-in vacib xüsusiyyəti metodların idempotentliyidir. GET, HEAD, PUT, DELETE və OPTIONS idempotentdir: eyni sorğunun təkrar yerinə yetirilməsi ilk icradan sonra serverin vəziyyətini dəyişmir. POST, PATCH və CONNECT idempotent deyil — hər çağırış yeni resurs yarada və ya vəziyyəti dəyişə bilər. Mobil inkişaf üçün idempotentliyi anlamaq kritikdir: şəbəkə xətası səbəbindən sorğunun təkrar göndərilməsi zamanı müştəri sorğunu təkrarlamağın təhlükəsiz olub-olmadığını bilməlidir.

HTTPS və TLS şifrələmə

HTTPS ötürülən məlumatları qorumaq üçün TLS (Transport Layer Security) kriptoqrafik protokolundan istifadə edir. TLS — 1995-ci ildə Netscape şirkəti tərəfindən hazırlanmış SSL-in (Secure Sockets Layer) varisidir. SSL 2.0 və 3.0 versiyaları köhnəlmiş və təhlükəsiz hesab edilmir; TLS 1.2 (2008-ci ildə buraxılıb) və TLS 1.3 (2018-ci ildə buraxılıb) müasir versiyaları hər yerdə istifadə olunur. TLS 1.3, xüsusilə, əlaqə qurma vaxtını 2 round-trips-dən 1-ə endirir ki, bu da mobil cihazlarda yükləməni əhəmiyyətli dərəcədə sürətləndirir.

TLS əl sıxması (handshake) prosesi aşağıdakı mərhələləri əhatə edir:

• Client Hello — müştəri dəstəklənən TLS versiyalarının və şifrə dəstlərinin siyahısını göndərir
• Server Hello — server TLS versiyasını və şifrə dəstini seçir, öz SSL/TLS sertifikatını göndərir
• Sertifikatın yoxlanılması — müştəri serverin sertifikatını kök CA-ya qədər etibar zənciri vasitəsilə yoxlayır
• Açar mübadiləsi — müştəri və server ümumi gizli açar (seans açarı) yaradır
• Switch Cipher — hər iki tərəf şifrələnmiş əlaqəyə keçidi təsdiqləyir

SSL/TLS sertifikatının yoxlanılması — təhlükəsizlik üçün kritik mərhələdir. Müştəri sertifikatın: müddətinin bitmədiyini, etibarlı sertifikat mərkəzi (CA) tərəfindən imzalandığını, URL-dəki domenə uyğun olduğunu və ləğv edilmədiyini (CRL və ya OCSP vasitəsilə) yoxlayır. Mobil tətbiqlərdə Certificate Pinning — konkret sertifikata və ya serverin açıq açarına bağlanma tövsiyə olunur. Bu, CA-nın kompromitasiyası halında belə MITM hücumlarının qarşısını alır. Lakin pinning ehtiyat tələb edir: sertifikat dəyişdirilərkən tətbiq əvvəlcədən yenilənməlidir.

HTTP sorğu və cavab strukturu

HTTP sorğusu üç hissədən ibarətdir: başlanğıc sətri (request line), başlıqlar (headers) və isteğe bağlı gövdə (body). Başlanğıc sətri HTTP metodunu, sorğu URL-ni və HTTP versiyasını ehtiva edir. Başlıqlar meta-məlumat ötürür: məzmun növü, autentifikasiya tokenləri, keşləmə parametrləri. Gövdə yalnız məlumat ötürən metodlarda (POST, PUT, PATCH) mövcuddur və GET və DELETE-də yoxdur.

REST API-yə HTTP sorğusu nümunəsi:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

HTTP cavabı analoji struktur malikdir: HTTP versiyası və status kodu ilə başlanğıc sətri, başlıqlar və gövdə. Status kodu — sorğunun emal nəticəsini müəyyən edən üçrəqəmli rəqəmdir. Cavab başlıqlarına Content-Type, Content-Length, Cache-Control, Set-Cookie və digərləri daxildir. Cavab gövdəsi Content-Type-də göstərilən formatda tələb olunan məlumatları ehtiva edir (adətən API üçün JSON, veb-səhifələr üçün HTML, media məzmunu üçün şəkillər).

Başlıqlar HTTP-in işində kritik rol oynayır. Content-Type və Accept məlumat formatını idarə edir. Authorization giriş tokenlərini ötürür. Cache-Control keşləməni idarə edir. CORS başlıqları (Access-Control-Allow-Origin) brauzerlərdə digər domenlərdən girişi nəzarət edir. User-Agent müştəri tətbiqini identifikasiya edir. Mobil tətbiqlər üçün keşləmə başlıqları xüsusilə vacibdir — onlar ötürülən məlumatların həcmini azaltmağa və zəif siqnalda işi yaxşılaşdırmağa imkan verir.

HTTP status kodları

HTTP status kodları birinci rəqəmlə göstərilən beş sinfə qruplaşdırılır: 1xx (məlumat), 2xx (uğur), 3xx (yönləndirmə), 4xx (müştəri xətası), 5xx (server xətası). Bu kodları başa düşmək mobil tətbiqdə cavabların düzgün emalı üçün zəruridir: 2xx uğur deməkdir və məlumatlar göstərilə bilər, 4xx sorğuda problemi göstərir (istifadəçiyə xəta göstərilməlidir), 5xx serverdə problemi göstərir (sorğu sonra təkrarlanmalıdır).

Mobil tətbiqlər üçün 401 Unauthorized kodunun emalı xüsusi əhəmiyyət kəsb edir. Bu kodu aldıqdan sonra müştəri Refresh Token vasitəsilə giriş tokenini yeniləməyə çalışmalı və orijinal sorğunu təkrarlamalıdır. Tokenin yenilənməsi də 401 qaytararsa, istifadəçi giriş ekranına yönləndirilməlidir. Bu məntiq adətən Interceptor (OkHttp) və ya şəbəkə müştərisinin middleware qatında həyata keçirilir.

HTTP/1.1, HTTP/2 və HTTP/3

HTTP/1.1, 1999-cu ildə nəşr edilmiş, hələ də geniş istifadə olunan protokol versiyasıdır. Onun əsas çatışmazlığı — head-of-line blocking: eyni serverə sorğular ardıcıl yerinə yetirilir, hər növbətisi əvvəlkinin bitməsini gözləyir. Bu məhdudiyyəti keçmək üçün brauzerlər eyni domenə 6–8 paralel TCP əlaqəsi açır ki, bu da server yükünü və yaddaş istehlakını artırır. HTTP/1.1 həmçinin başlıqları şifrələnməmiş formada ötürür və server push-u dəstəkləmir.

HTTP/2 (2015) multipleksləşdirmə vasitəsilə bloklama problemini həll edir — çoxsaylı məlumat axınları bir TCP əlaqəsi ilə eyni vaxtda ötürülür. Server müştəri tələb etməzdən əvvəl resursları göndərə bilər (server push). HTTP/2 həmçinin HPACK vasitəsilə başlıqları sıxışdırır ki, bu da ötürülən məlumatların həcmini azaldır. Mobil tətbiqlər üçün HTTP/2 xüsusilə faydalıdır: bir əlaqə bir neçəsini əvəz edir, TLS əl sıxma vaxtını və batareya istehlakını azaldır.

HTTP/3 (2022) — TCP əvəzinə QUIC (Quick UDP Internet Connections) istifadə edən protokolun ən son versiyasıdır. QUIC UDP üzərində işləyir, nəqliyyat protokolu səviyyəsində head-of-line blocking problemini aradan qaldırır. HTTP/3 əlaqə qurma vaxtını ən yaxşı halda 0 round-trips-ə (təkrar qoşulmalarda) və ilk qoşulmada 1 round-trip-ə endirir ki, bu da 2–3 round-trips olan HTTP/2-dən əhəmiyyətli dərəcədə sürətlidir. Mobil cihazlar üçün HTTP/3 Wi-Fi və mobil şəbəkə arasında keçid zamanı xüsusilə effektivdir — QUIC IP ünvanı deyil, əlaqə identifikatorundan istifadə etdiyi üçün əlaqə kəsilmir.

Mobil inkişafda HTTPS

Mobil tətbiqlərdə HTTPS istifadəsi — tövsiyə deyil, məcburi tələbdir. Android 9 (API 28) və iOS 9-dan (ATS — App Transport Security) başlayaraq, bütün şəbəkə sorğuları standart olaraq HTTPS istifadə etməlidir. HTTP sorğuları sistem tərəfindən bloklanır və onlara icazə vermək üçün tətbiq konfiqurasiyasında açıq istisna tələb olunur. Google Play Store və App Store parollar, tokenlər və şəxsi məlumatlar daxil olmaqla, məxfi məlumatları HTTP ilə ötürən tətbiqləri rədd edir.

Android-də mobil tətbiqdə HTTPS konfiqurasiyası aşağıdakıları əhatə edir:

<!-- AndroidManifest.xml — şəbəkə sorğularına icazə -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — HTTPS konfiqurasiyası -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

iOS-da oxşar konfiqurasiya NSAppTransportSecurity açarı ilə Info.plist vasitəsilə yerinə yetirilir. Mobil tətbiqlərdə HTTPS trafikini sazlamaq üçün proxy alətlərindən istifadə olunur: Charles Proxy, Proxyman və ya mitmproxy. Onlar cihazda etibarlı SSL sertifikatının quraşdırılmasını tələb edir. İstehsal qurğularında sazlama imkanını söndürmək və Certificate Pinning-in düzgün konfiqurasiya edildiyini yoxlamaq lazımdır. Android-də OkHttp-nun CertificatePinner və ya iOS-da TrustManager ilə SecTrustEvaluate istifadəsi — pinning-in həyata keçirilməsi üçün standart yanaşmalardır.

Mobil inkişafda HTTPS təhlükəsizliyinin vacib aspekti — SSL Pinning-dir. Pinning olmadan tətbiq tanınmış CA tərəfindən imzalanmış istənilən sertifikata etibar edir. CA kompromitasiya olunarsa, təcavüzkar tətbiq trafikini ələ keçirə bilər. Pinning tətbiqi konkret sertifikata və ya serverin açıq açarına bağlayır. Serverdə sertifikat dəyişdirilərkən tətbiq yeniləməsi buraxılmalıdır, buna görə pinning ehtiyatla planlaşdırılır — yuxarı CA-nın sertifikatına bağlanır və ya bir neçə ehtiyat açar istifadə olunur.