SSL/TLS: concepte cheie și protocoale în programare

Ce este SSL/TLS?

SSL (Secure Sockets Layer) și TLS (Transport Layer Security) — protocoale criptografice care asigură transmiterea sigură a datelor prin rețea. SSL, dezvoltat de Netscape în anii 1990, a fost declarat învechit după versiunea 3.0 din cauza vulnerabilităților POODLE și BEAST. TLS, succesorul său, a trecut prin versiunile 1.0, 1.1, 1.2 și 1.3 — în prezent doar TLS 1.2 și TLS 1.3 sunt considerate actuale. Toate platformele mobile moderne necesită utilizarea TLS pentru conexiunile de rețea, iar App Store și Google Play verifică acest lucru în faza de review.

De ce au nevoie aplicațiile mobile de TLS

Fără TLS, traficul între aplicație și server este transmis text clar — oricine din aceeași rețea Wi-Fi poate intercepta nume de utilizator, parole, tokenuri și date personale ale utilizatorilor cu ajutorul Wireshark sau tcpdump. TLS criptează toate datele transmise (criptare la nivel de transport) și verifică autenticitatea serverului prin lanțul de certificate X.509. Potrivit IETF (2018), TLS 1.3 utilizează doar cifruri moderne AEAD (AES-GCM, ChaCha20-Poly1305), excluzând algoritmii învechiți precum RC4 și 3DES.

HTTPS și TLS

HTTPS (HTTP Secure) — este HTTP peste TLS. Când o aplicație mobilă face o cerere prin https://, mai întâi stabilește o conexiune TLS cu serverul, apoi transmite antetele HTTP și corpul cererii prin canalul criptat. Fără HTTPS, nicio API serioasă nu ar trebui să funcționeze — aceasta este igiena de bază a securității. Potrivit OWASP (2026), conexiunile nesecurizate se află în top 3 vulnerabilități ale aplicațiilor mobile.

Cum funcționează TLS Handshake

TLS Handshake — procesul de stabilire a unei conexiuni sigure între client și server. Părțile negociază versiunea protocolului, aleg setul de cifruri (cipher suite), fac schimb de chei prin criptografie asimetrică și verifică certificatele. În TLS 1.2, handshake-ul necesită 2 Round Trip Time (2 RTT): client → server cu ClientHello, server → client cu ServerHello și Certificate, apoi mesajele finale Finished. TLS 1.3 reduce acest proces la 1 RTT.

Etapele detaliate ale handshake-ului TLS 1.2

Prima etapă: ClientHello — clientul trimite versiunile TLS suportate, lista de seturi de cifruri și un număr aleator. Serverul răspunde cu ServerHello, alegând versiunea și setul de cifruri, trimite propriul certificat X.509 (Certificate) și mesajul ServerHelloDone. Clientul verifică certificatul prin lanțul autorităților de certificare de încredere (CA), generează pre-master secret, îl criptează cu cheia publică din certificat și îl trimite serverului în ClientKeyExchange. După aceasta, ambele părți generează cheile de sesiune și fac schimb de mesaje ChangeCipherSpec și Finished. Din acest moment, toate datele sunt criptate simetric.

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

Exemplu de procesare a URLAuthenticationChallenge pe iOS prin URLSessionDelegate. Această metodă este apelată la fiecare TLS Handshake, permițând aplicației să verifice personalizat certificatul serverului. Pentru producție, adăugați verificarea certificatului prin SecTrustEvaluateWithError și comparați cu amprenta salvată anterior — abia apoi apelați useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — prima actualizare majoră a protocolului în 10 ani. Îmbunătățiri principale: handshake redus la 1 RTT (0 RTT pentru reconectări), seturi de cifruri învechite (RSA key exchange, CBC-mode) eliminate, criptarea perfectă înainte (PFS) obligatorie și protecție împotriva atacurilor downgrade prin signed transcript. Potrivit Qualys SSL Labs (2026), TLS 1.3 asigură protecție chiar și la compromiterea cheii pe termen lung a serverului datorită PFS.

0-RTT (Zero Round Trip Time) — caracteristică TLS 1.3 care permite clientului să trimită date imediat împreună cu ClientHello la reconectare prin PSK (Pre-Shared Key). Aceasta accelerează încărcarea ecranelor următoare în aplicațiile mobile, în special la cereri frecvente către același server. Totuși, datele 0-RTT nu sunt protejate împotriva atacurilor replay — pot fi interceptate și retrimise. Utilizați 0-RTT doar pentru cereri idempotente (GET, PUT) fără efecte secundare.

TLS pe iOS: App Transport Security

App Transport Security (ATS) — mecanismul Apple care necesită conexiuni HTTPS cu TLS 1.2 sau superior, activat implicit din iOS 9. ATS blochează toate conexiunile HTTP și HTTPS cu TLS sub 1.2. Dezvoltatorul poate configura excepții în Info.plist prin NSAppTransportSecurity pentru domenii specifice, dar Apple recomandă minimizarea excepțiilor și utilizarea HTTPS peste tot. Încălcarea cerințelor ATS este un motiv de respingere a aplicației la review-ul App Store.

<!-- 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>

Configurarea ATS în Info.plist. NSAllowsArbitraryLoads setat pe false — toate conexiunile trebuie să utilizeze HTTPS. Pentru domeniul cdn.example.com este setată versiunea minimă TLS 1.2, NSAllowsLocalNetworking=true permite HTTP pentru rețeaua locală (util pentru serverele de dezvoltare). Apple recomandă insistent să nu activați NSAllowsArbitraryLoads fără NSExceptionDomains — aceasta trebuie să fie o excepție, nu o regulă generală.

TLS pe Android: Network Security Config

Network Security Config — mecanismul Android pentru configurarea HTTPS și TLS fără modificarea codului Java/Kotlin. Configurarea se definește în fișierul XML network_security_config.xml și se conectează în AndroidManifest prin atributul android:networkSecurityConfig. Suportă configurarea certificatelor de încredere (user și system CA), Certificate Pinning, dezactivarea HTTP necriptat, suprascrieri de debug și redirecționarea traficului.

<!-- 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>

Network Security Config pentru Android. Base-config interzice traficul necriptat și are încredere doar în certificatele CA de sistem (fără certificate de utilizator — protecție împotriva instalării certificatelor MitM de către utilizator). Domain-config pentru api.example.com conține pin-set cu amprenta SHA-256 a certificatului. Dacă certificatul serverului se schimbă înainte de data de expirare specificată, conexiunea va fi respinsă — aceasta este o formă strictă de Certificate Pinning.

Certificate Pinning și securitate

Certificate Pinning — tehnica de fixare a certificatului sau cheii publice a serverului în codul aplicației. La fiecare TLS Handshake, clientul compară certificatul serverului cu amprenta salvată anterior (hash SHA-256). Chiar dacă un atacator obține un certificat CA de încredere sau compromite o autoritate de certificare, nu poate efectua un atac MitM — aplicația verifică amprenta specifică, nu lanțul CA. Acest lucru este deosebit de important pentru aplicațiile financiare și aplicațiile cu date sensibile.

Riscuri și alternative Pinning

Certificate Pinning necesită prudență: la schimbarea certificatului pe server, toate versiunile vechi ale aplicației nu se vor mai putea conecta. Se recomandă stocarea mai multor amprente de rezervă (principal + de rezervă), specificarea datei de expirare a pin-set și implementarea unui mecanism fallback prin verificarea CA standard. Alternativa — Trust On First Use (TOFU), când aplicația reține certificatul la prima conexiune și avertizează utilizatorul la modificarea acestuia. Potrivit OWASP (2026), lipsa Certificate Pinning se află în top 3 vulnerabilități ale aplicațiilor mobile (M3: Insecure Communication).

Implementarea Pinning în Alamofire

În Alamofire 5+, Certificate Pinning se configurează prin ServerTrustManager cu PinnedCertificatesTrustEvaluator (verificarea întregului certificat) sau PublicKeysTrustEvaluator (doar cheia publică). Cheia publică este preferabilă — nu se schimbă la actualizarea certificatului la același CA. Creați un ServerTrustManager cu dicționarul [host: evaluator], transmiteți-l în Session și utilizați-l pentru toate cererile către API-uri protejate.