HTTP/HTTPS: ce este, protocoale de transmisie a datelor și criptarea TLS

Ce sunt HTTP și HTTPS?

HTTP (HyperText Transfer Protocol) — este un protocol la nivel de aplicație al modelului OSI, destinat transmiterii documentelor hipertext și a altor date în World Wide Web. Dezvoltat de Tim Berners-Lee în 1989, HTTP a trecut prin mai multe versiuni: de la HTTP/0.9 (numai cereri GET și răspunsuri HTML) până la HTTP/2 și HTTP/3 moderne. Protocolul funcționează după schema cerere-răspuns: clientul trimite o cerere către server, serverul o procesează și returnează un răspuns.

HTTPS (HTTP Secure) — este o extensie a protocolului HTTP care adaugă un nivel de criptare prin TLS (Transport Layer Security). HTTPS nu este un protocol separat — este o combinație între HTTP și TLS. Datele transmise prin HTTPS sunt criptate pe partea clientului și decriptate pe server, ceea ce le face inaccesibile pentru interceptare și falsificare. HTTPS asigură și autentificarea serverului prin certificate SSL/TLS, garantând că clientul se conectează la serverul real, nu la un atacator.

Diferența cheie între HTTP și HTTPS este securitatea. HTTP transmite datele în clar: orice nod de rețea între client și server poate citi conținutul cererii sau răspunsului. HTTPS criptează tot conținutul, inclusiv URL-ul, antetele și corpul cererii, lăsând vizibile doar adresa IP a serverului și portul de conectare. Pentru aplicațiile mobile care funcționează prin rețele Wi-Fi publice, HTTPS este o cerință obligatorie de securitate.

Cum funcționează HTTP

HTTP — este un protocol fără stare (stateless) care funcționează peste TCP/IP. Clientul stabilește o conexiune TCP cu serverul (de obicei pe portul 80 pentru HTTP sau 443 pentru HTTPS), trimite o cerere HTTP, primește un răspuns HTTP și închide conexiunea (în HTTP/1.1 conexiunea poate fi reutilizată). Fiecare interacțiune între client și server constă dintr-o cerere și un răspuns. Fără stare înseamnă că serverul nu stochează informații despre cererile anterioare ale clientului — fiecare cerere este procesată independent.

Procesul de interacțiune HTTP include următorii pași:

• Rezolvare DNS — browserul sau clientul convertește numele de domeniu în adresă IP prin DNS
• Handshake TCP — se stabilește conexiunea TCP printr-un handshake în trei pași (SYN, SYN-ACK, ACK)
• Handshake TLS — pentru HTTPS se stabilește suplimentar o conexiune criptată (schimb de certificate și chei)
• Cerere HTTP — clientul trimite metoda, URL-ul, antetele și opțional corpul cererii
• Răspuns HTTP — serverul returnează codul de stare, antetele și corpul răspunsului

O caracteristică importantă a HTTP este idempotența metodelor. GET, HEAD, PUT, DELETE și OPTIONS sunt idempotente: executarea repetată a aceleiași cereri nu schimbă starea serverului după prima execuție. POST, PATCH și CONNECT nu sunt idempotente — fiecare apel poate crea o resursă nouă sau poate modifica starea. Pentru dezvoltarea mobilă, înțelegerea idempotenței este critică: la retrimiterea unei cereri din cauza unei erori de rețea, clientul trebuie să știe dacă este sigur să repete cererea.

HTTPS și criptarea TLS

HTTPS utilizează protocolul criptografic TLS (Transport Layer Security) pentru a proteja datele transmise. TLS — succesorul SSL (Secure Sockets Layer), care a fost dezvoltat de compania Netscape în 1995. Versiunile SSL 2.0 și 3.0 sunt considerate învechite și nesigure; versiunile moderne TLS 1.2 (lansat în 2008) și TLS 1.3 (lansat în 2018) sunt utilizate pe scară largă. TLS 1.3, în special, reduce timpul de stabilire a conexiunii de la 2 round-trips la 1, ceea ce accelerează semnificativ încărcarea pe dispozitivele mobile.

Procesul de handshake TLS include următoarele etape:

• Client Hello — clientul trimite lista versiunilor TLS și a seturilor de criptare suportate
• Server Hello — serverul alege versiunea TLS și setul de criptare, trimite propriul certificat SSL/TLS
• Verificarea certificatului — clientul verifică certificatul serverului prin lanțul de încredere până la CA rădăcină
• Schimbul de chei — clientul și serverul generează o cheie secretă comună (cheie de sesiune)
• Switch Cipher — ambele părți confirmă trecerea la conexiunea criptată

Verificarea certificatului SSL/TLS — o etapă critică pentru securitate. Clientul verifică dacă certificatul: nu a expirat, este semnat de o autoritate de certificare de încredere (CA), corespunde domeniului din URL și nu a fost revocat (prin CRL sau OCSP). În aplicațiile mobile se recomandă utilizarea Certificate Pinning — fixarea de un certificat specific sau de cheia publică a serverului. Aceasta previne atacurile MITM chiar și în cazul compromiterii CA. Totuși, pinning necesită prudență: la schimbarea certificatului, aplicația trebuie actualizată în prealabil.

Structura cererii și răspunsului HTTP

Cererea HTTP constă din trei părți: linia de start (request line), antetele (headers) și opțional corpul (body). Linia de start conține metoda HTTP, URL-ul cererii și versiunea HTTP. Antetele transmit metainformații: tipul conținutului, tokenurile de autentificare, setările de cache. Corpul este prezent doar în metodele care transmit date (POST, PUT, PATCH) și lipsește în GET și DELETE.

Exemplu de cerere HTTP către REST API:

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

Răspunsul HTTP are o structură analogă: linia de start cu versiunea HTTP și codul de stare, antetele și corpul. Codul de stare — un număr din trei cifre care determină rezultatul procesării cererii. Antetele răspunsului includ Content-Type, Content-Length, Cache-Control, Set-Cookie și altele. Corpul răspunsului conține datele solicitate în formatul specificat în Content-Type (de obicei JSON pentru API, HTML pentru pagini web, imagini pentru conținut media).

Antetele joacă un rol critic în funcționarea HTTP. Content-Type și Accept gestionează formatul datelor. Authorization transmite tokenurile de acces. Cache-Control gestionează stocarea în cache. Antetele CORS (Access-Control-Allow-Origin) controlează accesul din alte domenii în browsere. User-Agent identifică aplicația client. Pentru aplicațiile mobile, antetele de gestionare a cache-ului sunt deosebit de importante — ele permit reducerea volumului de date transmise și îmbunătățirea funcționării la semnal slab.

Coduri de stare HTTP

Codurile de stare HTTP sunt grupate în cinci clase, indicate de prima cifră: 1xx (informaționale), 2xx (succes), 3xx (redirecționare), 4xx (eroare client), 5xx (eroare server). Înțelegerea acestor coduri este necesară pentru procesarea corectă a răspunsurilor într-o aplicație mobilă: 2xx înseamnă succes și datele pot fi afișate, 4xx indică o problemă în cerere (trebuie afișată o eroare utilizatorului), 5xx — o problemă pe server (cererea trebuie repetată mai târziu).

Pentru aplicațiile mobile, gestionarea codului 401 Unauthorized are o importanță deosebită. La primirea acestui cod, clientul trebuie să încerce să reîmprospăteze tokenul de acces prin Refresh Token și să repete cererea originală. Dacă reîmprospătarea tokenului returnează și ea 401, utilizatorul trebuie direcționat către ecranul de autentificare. Această logică este de obicei implementată în Interceptor (OkHttp) sau în stratul middleware al clientului de rețea.

HTTP/1.1, HTTP/2 și HTTP/3

HTTP/1.1, publicat în 1999, rămâne încă o versiune larg utilizată a protocolului. Principalul său dezavantaj — head-of-line blocking: cererile către același server sunt executate secvențial, fiecare următoare așteaptă finalizarea celei anterioare. Pentru a ocoli această limitare, browserele deschid 6–8 conexiuni TCP paralele către același domeniu, ceea ce crește încărcarea serverului și consumul de memorie. HTTP/1.1 transmite și antetele în formă necriptată și nu suportă server push.

HTTP/2 (2015) rezolvă problema blocării prin multiplexare — fluxuri multiple de date sunt transmise printr-o singură conexiune TCP simultan. Serverul poate trimite resurse către client înainte ca acesta să le solicite (server push). HTTP/2 comprimă și antetele prin HPACK, ceea ce reduce volumul datelor transmise. Pentru aplicațiile mobile, HTTP/2 este deosebit de util: o singură conexiune înlocuiește mai multe, reducând timpul de handshake TLS și consumul bateriei.

HTTP/3 (2022) — cea mai recentă versiune a protocolului, care utilizează QUIC (Quick UDP Internet Connections) în loc de TCP. QUIC funcționează pe UDP, eliminând problema head-of-line blocking la nivelul protocolului de transport. HTTP/3 reduce timpul de stabilire a conexiunii la 0 round-trips în cel mai bun caz (la reconectări) și la 1 round-trip la prima conectare, ceea ce este semnificativ mai rapid decât HTTP/2 cu 2–3 round-trips. Pentru dispozitivele mobile, HTTP/3 este deosebit de eficient la comutarea între Wi-Fi și rețeaua mobilă — conexiunea nu se întrerupe, deoarece QUIC utilizează un identificator de conexiune, nu o adresă IP.

HTTPS în dezvoltarea mobilă

Utilizarea HTTPS în aplicațiile mobile — nu este o recomandare, ci o cerință obligatorie. Începând cu Android 9 (API 28) și iOS 9 (ATS — App Transport Security), toate cererile de rețea trebuie să utilizeze HTTPS în mod implicit. Cererile HTTP sunt blocate de sistem, iar pentru a le permite este necesară o excepție explicită în configurația aplicației. Google Play Store și App Store resping aplicațiile care transmit date confidențiale prin HTTP, inclusiv parole, tokenuri și date personale.

Configurarea HTTPS într-o aplicație mobilă pe Android include:

<!-- AndroidManifest.xml — permisiune pentru cereri de rețea -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — configurare HTTPS -->
<?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>

Pe iOS, configurarea analogică se face prin Info.plist cu cheia NSAppTransportSecurity. Pentru depanarea traficului HTTPS în aplicațiile mobile se utilizează instrumente proxy: Charles Proxy, Proxyman sau mitmproxy. Acestea necesită instalarea unui certificat SSL de încredere pe dispozitiv. În versiunile de producție, trebuie dezactivată posibilitatea de depanare și verificată configurarea corectă a Certificate Pinning. Utilizarea OkHttp pe Android cu CertificatePinner sau TrustManager pe iOS cu SecTrustEvaluate — abordări standard pentru implementarea pinning.

Un aspect important al securității HTTPS în dezvoltarea mobilă — SSL Pinning. Fără pinning, aplicația are încredere în orice certificat semnat de un CA cunoscut. Dacă CA este compromis, un atacator poate intercepta traficul aplicației. Pinning leagă aplicația de un certificat specific sau de cheia publică a serverului. La schimbarea certificatului pe server, este necesară lansarea unei actualizări a aplicației, de aceea pinning-ul se planifică cu rezervă — se leagă de certificatul CA superior sau se utilizează mai multe chei de rezervă.