SSL/TLS — cos'è, protocolli e principio di funzionamento della crittografia

Cos'è SSL/TLS?

SSL (Secure Sockets Layer) è un protocollo sviluppato da Netscape nel 1995 per proteggere il traffico web. La prima versione, SSL 1.0, non è mai stata pubblicata; SSL 2.0 (1995) e SSL 3.0 (1996) sono stati utilizzati fino ai primi anni 2000, ma contenevano vulnerabilità critiche. A SSL è succeduto TLS (Transport Layer Security) — una versione migliorata standardizzata dall'IETF. TLS 1.0 (1999) era basato su SSL 3.0, mentre le versioni successive TLS 1.1 (2006), TLS 1.2 (2008) e TLS 1.3 (2018) si sono gradualmente allontanate dall'architettura originale, aggiungendo nuovi algoritmi di crittografia e correggendo vulnerabilità. Oggi SSL è considerato obsoleto e tutti i sistemi moderni utilizzano TLS, sebbene entrambi i protocolli siano spesso menzionati insieme come SSL/TLS per inerzia.

Storia del protocollo

La storia di SSL/TLS è iniziata con la necessità di trasmissione sicura dei dati nel web primordiale. Nel 1994, Netscape sviluppò SSL 1.0 per il suo browser Navigator, ma il protocollo non fu mai pubblicato a causa di seri problemi di sicurezza. SSL 2.0 uscì nel 1995 e fu utilizzato nella pratica, ma conteneva numerose vulnerabilità: mancanza di protezione contro attacchi Man-in-the-Middle, algoritmi di crittografia deboli e suscettibilità ad attacchi di troncamento. SSL 3.0 (1996) risolse la maggior parte dei problemi, ma entro il 2014 fu scoperta la vulnerabilità POODLE, dopo la quale l'IETF dichiarò ufficialmente obsolete tutte le versioni di SSL. TLS 1.0–1.3 hanno progressivamente migliorato la robustezza crittografica, le prestazioni e la privacy, con TLS 1.3 che ha ridotto l'handshake da due round-trip a uno — cosa criticamente importante per le applicazioni mobili con connessioni instabili.

Come funziona l'Handshake SSL/TLS

Handshake è il processo di stabilimento di una connessione sicura tra un client e un server. Consiste in diversi passaggi sequenziali durante i quali le parti concordano la versione del protocollo, selezionano gli algoritmi di crittografia, scambiano le chiavi e si autenticano reciprocamente. In TLS 1.3, l'handshake richiede un solo round-trip di rete (1-RTT), mentre in TLS 1.2 ne servivano due (2-RTT).

Il primo passo è l'invio da parte del client di un ClientHello — un messaggio contenente un elenco di versioni TLS supportate, suite di cifratura e un numero casuale. Il server risponde con un ServerHello contenente la versione e la cifratura scelte, il suo certificato X.509 e una firma digitale. Il client verifica il certificato attraverso la catena di autorità di certificazione (CA), genera una chiave di sessione e la invia crittografata con la chiave pubblica del server estratta dal certificato. Dopo la conferma dal server, inizia la trasmissione sicura dei dati. L'intero handshake richiede 1–3 millisecondi sui dispositivi moderni, rendendolo impercettibile per l'utente.

Certificati X.509 e catena di fiducia

La base dell'autenticazione TLS è l'Infrastruttura a Chiave Pubblica (PKI) costruita su certificati in formato X.509. Ogni certificato contiene: un nome di dominio (Common Name o Subject Alternative Name), la chiave pubblica del server, il nome dell'emittente (Autorità di Certificazione), una data di scadenza e la firma digitale della CA. Il client verifica il certificato del server lungo la catena di fiducia: dal certificato del server fino alla CA radice, il cui certificato è integrato nel sistema operativo. Sui dispositivi Android, i certificati radice sono memorizzati nel keystore di sistema, aggiornato tramite Google Play Services; su iOS — tramite gli aggiornamenti iOS. Se un anello della catena si rompe (certificato scaduto, mancata corrispondenza del dominio, CA sconosciuta), il client interrompe la connessione. Per i certificati auto-firmati (usati in sviluppo), è richiesta la fiducia esplicita — su Android tramite Network Security Config, su iOS tramite NSExceptionDomains in Info.plist. Il processo di validazione della catena di certificati include anche la verifica dello stato di revoca tramite CRL (Certificate Revocation List) o OCSP (Online Certificate Status Protocol), sebbene sui dispositivi mobili le richieste OCSP vengano spesso saltate per accelerare la connessione — questo è un compromesso tra sicurezza e prestazioni che gli architetti dovrebbero considerare.

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