SSL/TLS — ce este, protocoalele și principiul de funcționare a criptării

Ce este SSL/TLS?

SSL (Secure Sockets Layer) — este un protocol dezvoltat de compania Netscape în 1995 pentru protejarea traficului web. Prima versiune SSL 1.0 nu a fost niciodată publicată, SSL 2.0 (1995) și SSL 3.0 (1996) au fost utilizate până la începutul anilor 2000, dar conțineau vulnerabilități critice. În locul SSL a venit TLS (Transport Layer Security) — o versiune îmbunătățită standardizată de IETF. TLS 1.0 (1999) s-a bazat pe SSL 3.0, iar versiunile ulterioare TLS 1.1 (2006), TLS 1.2 (2008) și TLS 1.3 (2018) s-au îndepărtat treptat de arhitectura originală, adăugând noi algoritmi de criptare și eliminând vulnerabilități. Astăzi SSL este considerat învechit, iar toate sistemele moderne utilizează TLS, deși din inerție ambele protocoale sunt adesea menționate împreună ca SSL/TLS.

Istoria creării protocolului

Istoria SSL/TLS a început cu necesitatea transmiterii securizate a datelor în primele zile ale web-ului. În 1994, compania Netscape a dezvoltat SSL 1.0 pentru browserul său Navigator, dar protocolul nu a fost niciodată publicat din cauza problemelor grave de securitate. SSL 2.0 a fost lansat în 1995 și a fost utilizat în practică, însă conținea numeroase vulnerabilități: lipsa protecției împotriva atacurilor Man-in-the-Middle, algoritmi de criptare slabi și vulnerabilitate la atacuri de tip truncation. SSL 3.0 (1996) a remediat majoritatea problemelor, dar până în 2014 a fost descoperită vulnerabilitatea POODLE, după care IETF a declarat oficial toate versiunile SSL învechite. TLS 1.0–1.3 au îmbunătățit succesiv rezistența criptografică, performanța și confidențialitatea, TLS 1.3 reducând handshake-ul de la două round-trip-uri la unul, ceea ce este critic pentru aplicațiile mobile cu conexiune instabilă.

Cum funcționează SSL/TLS Handshake

Handshake — este procesul de stabilire a conexiunii securizate între client și server. Acesta constă din mai mulți pași consecutivi, în timpul cărora părțile negociază versiunea protocolului, aleg algoritmii de criptare, fac schimb de chei și se autentifică reciproc. În TLS 1.3, handshake-ul durează o singură interacțiune de rețea (1-RTT), în timp ce în TLS 1.2 erau necesare două (2-RTT).

Primul pas: clientul trimite ClientHello — un mesaj care conține lista versiunilor TLS acceptate, setul de cifruri (cipher suites) și un număr aleator. Serverul răspunde cu ServerHello, care include versiunea și cifrul selectat, propriul certificat X.509 și semnătura digitală. Clientul verifică certificatul prin lanțul autorităților de certificare (CA), generează o cheie de sesiune și o trimite criptată cu cheia publică a serverului din certificat. După confirmarea de către server, începe transmiterea securizată a datelor. Întregul handshake se realizează în 1–3 milisecunde pe dispozitivele moderne, ceea ce îl face invizibil pentru utilizator.

Certificatele X.509 și lanțul de încredere

Baza autentificării TLS o constituie infrastructura cheii publice (PKI) construită pe certificate de format X.509. Fiecare certificat conține: numele domeniului (Common Name sau Subject Alternative Name), cheia publică a serverului, numele emitentului (Certificate Authority), perioada de valabilitate și semnătura digitală a CA. Clientul verifică certificatul serverului prin lanțul de încredere: de la certificatul serverului până la CA rădăcină, al cărui certificat este încorporat în sistemul de operare. Pe dispozitivele Android, certificatele rădăcină sunt stocate în depozitul sistemului, actualizat prin Google Play Services; în iOS — prin iOS Updates. La încălcarea oricărei verigi a lanțului (certificat expirat, nepotrivirea domeniului, CA necunoscut), clientul întrerupe conexiunea. Pentru certificatele auto-semnate (utilizate în dezvoltare) este necesară o încredere explicită — în Android prin Network Security Config, în iOS prin NSExceptionDomains în Info.plist. Procesul de validare a lanțului de certificate include, de asemenea, verificarea stării de revocare prin CRL (Certificate Revocation List) sau OCSP (Online Certificate Status Protocol), deși pe dispozitivele mobile solicitările OCSP sunt adesea omise pentru accelerarea conexiunii — acesta este un compromis între securitate și performanță pe care arhitecții trebuie să-l ia în considerare.

SSL vs TLS: diferențe cheie

Deși termenii SSL și TLS sunt adesea utilizați ca sinonime, există diferențe tehnice fundamentale între ei care afectează securitatea și performanța aplicațiilor mobile.

Diferența principală a TLS 1.3 față de predecesori — utilizarea obligatorie a Perfect Forward Secrecy (PFS) prin protocolul ECDHE. Aceasta înseamnă că, chiar dacă un atacator obține acces la cheia privată a serverului, nu va putea decripta traficul interceptat anterior. Pentru aplicațiile mobile, unde spargerea serverului constituie o amenințare reală, TLS 1.3 cu PFS este o cerință obligatorie de securitate.

Vulnerabilități cunoscute ale versiunilor vechi

Versiunile vechi ale SSL și TLS au vulnerabilități documentate care le fac improprii pentru utilizarea în producție. POODLE (CVE-2014-3566) atacă SSL 3.0 prin padding oracle, permițând decriptarea cookie-ului de sesiune în 256 de cereri. BEAST (CVE-2011-3389) exploatează vulnerabilitatea TLS 1.0 în modul CBC printr-un IV predictibil. Heartbleed (CVE-2014-0160) — nu este o vulnerabilitate a protocolului, ci o eroare în implementarea OpenSSL, care permite citirea memoriei serverului: conform Netcraft, în 2014 peste 500 de mii de servere erau vulnerabile. Începând cu Android 10 (API 29) și iOS 13, toate protocoalele menționate sunt dezactivate la nivel de sistem. Cu toate acestea, dezvoltatorii ar trebui să verifice configurația serverului prin SSL Labs Test (qualys.com) înainte de lansarea aplicației pentru a se asigura că nu există cipher suites învechite și că TLS 1.3 este acceptat.

Cum protejează SSL/TLS datele în aplicațiile mobile

În aplicațiile mobile, TLS protejează datele la trei niveluri: criptarea conținutului (nimeni în afară de server nu poate citi datele), verificarea integrității (datele nu pot fi modificate în tranzit) și autentificarea serverului (clientul este sigur că se conectează la serverul corect). Autentificarea este deosebit de critică: fără ea, un atacator poate substitui serverul prin DNS-spoofing sau printr-un punct de acces Wi-Fi fals.

Conform studiului Google Play Protect (2024), 76% dintre aplicațiile Android utilizează TLS corect cu verificarea certificatelor. Restul de 24% comit erori: dezactivează verificarea certificatelor pentru testare (și uită să o activeze în producție), utilizează certificate auto-semnate fără validare sau permit protocoalele învechite SSL 3.0 și TLS 1.0. Apple App Transport Security (ATS) în iOS impune TLS 1.2 cel puțin din 2017, iar începând cu iOS 15 utilizează implicit TLS 1.3 pentru toate solicitările de rețea. Pentru protecție suplimentară, se recomandă și implementarea Certificate Pinning — fixarea la un certificat specific al serverului.

Implementarea SSL/TLS în aplicațiile mobile

Să examinăm un exemplu de configurare a conexiunii securizate HTTPS în Android utilizând OkHttp — una dintre cele mai populare biblioteci pentru lucrul cu rețeaua. Configurarea corectă include utilizarea forțată a TLS 1.3 și verificarea certificatelor.

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

În acest exemplu, limităm setul de versiuni TLS acceptate doar la protocoalele 1.3 și 1.2, excluzând TLS 1.0/1.1 învechite. Cipher suites sunt selectate din algoritmi moderni cu mod AEAD și Perfect Forward Secrecy obligatorie. HostnameVerifier verifică corespondența numelui de gazdă cu certificatul. Pentru iOS, configurarea similară se realizează prin configurarea URLSession cu parametrul tlsMinimumSupportedProtocolVersion, unde se specifică .TLSv13. Suplimentar, în iOS se poate seta tlsMaximumSupportedProtocolVersion pentru limitarea limitei superioare a versiunilor — acest lucru este util pentru compatibilitatea cu serverele vechi care nu au trecut încă la TLS 1.3. O astfel de configurare garantează nivelul maxim de securitate în timpul transmiterii datelor în aplicația mobilă.