SSL/TLS: concetti chiave e protocolli nello sviluppo

Cos'è SSL/TLS?

SSL (Secure Sockets Layer) e TLS (Transport Layer Security) sono protocolli crittografici che garantiscono la trasmissione sicura dei dati sulla rete. SSL, sviluppato da Netscape negli anni '90, è considerato obsoleto dopo la versione 3.0 a causa delle vulnerabilità POODLE e BEAST. TLS, il suo successore, ha attraversato le versioni 1.0, 1.1, 1.2 e 1.3 — solo TLS 1.2 e TLS 1.3 sono considerati attuali. Tutte le piattaforme mobili moderne richiedono TLS per le connessioni di rete, e App Store e Google Play lo verificano durante la revisione.

Perché TLS per le applicazioni mobili

Senza TLS, il traffico tra l'applicazione e il server viene trasmesso in chiaro — chiunque sulla stessa rete Wi-Fi può intercettare login, password, token e dati personali degli utenti usando Wireshark o tcpdump. TLS crittografa tutti i dati trasmessi (crittografia a livello di trasporto) e verifica l'autenticità del server tramite una catena di certificati X.509. Secondo IETF (2018), TLS 1.3 utilizza solo cifrari AEAD moderni (AES-GCM, ChaCha20-Poly1305), escludendo algoritmi obsoleti come RC4 e 3DES.

HTTPS e TLS

HTTPS (HTTP Secure) è HTTP su TLS. Quando un'applicazione mobile effettua una richiesta tramite https://, stabilisce prima una connessione TLS con il server, quindi trasmette le intestazioni HTTP e il corpo della richiesta attraverso il canale crittografato. Senza HTTPS, nessuna API seria dovrebbe funzionare — è l'igiene di sicurezza di base. Secondo OWASP (2026), le connessioni non sicure rientrano tra le prime 3 vulnerabilità delle applicazioni mobili.

Come funziona TLS Handshake

TLS Handshake è il processo di stabilimento di una connessione sicura tra un client e un server. Le parti negoziano la versione del protocollo, selezionano una suite di cifratura (cipher suite), scambiano chiavi tramite crittografia asimmetrica e verificano i certificati. In TLS 1.2, l'handshake richiede 2 Round Trip Time (2 RTT): client → server con ClientHello, server → client con ServerHello e Certificate, quindi i messaggi finali Finished. TLS 1.3 riduce questo processo a 1 RTT.

Fasi dettagliate dell'handshake TLS 1.2

Prima fase: ClientHello — il client invia le versioni TLS supportate, un elenco di suite di cifratura e un numero casuale. Il server risponde con ServerHello, selezionando una versione e una suite di cifratura, invia il suo certificato X.509 (Certificate) e il messaggio ServerHelloDone. Il client verifica il certificato tramite una catena di autorità di certificazione (CA) fidate, genera un pre-master secret, lo crittografa con la chiave pubblica del certificato e lo invia al server in ClientKeyExchange. Successivamente, entrambe le parti generano chiavi di sessione e scambiano i messaggi ChangeCipherSpec e Finished. Da questo momento, tutti i dati vengono crittografati simmetricamente.

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

Esempio di gestione di URLAuthenticationChallenge su iOS tramite URLSessionDelegate. Questo metodo viene chiamato durante ogni TLS Handshake, consentendo all'applicazione di eseguire una verifica personalizzata del certificato del server. Per l'uso in produzione, aggiungere la verifica del certificato tramite SecTrustEvaluateWithError e confrontare con un'impronta precedentemente salvata — solo dopo chiamare useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) è il primo importante aggiornamento del protocollo in 10 anni. Principali miglioramenti: handshake ridotto a 1 RTT (0 RTT per connessioni ripetute), rimozione delle suite di cifratura obsolete (scambio di chiavi RSA, modalità CBC), Perfect Forward Secrecy (PFS) obbligatorio e protezione dagli attacchi di downgrade tramite signed transcript. Secondo Qualys SSL Labs (2026), TLS 1.3 fornisce protezione anche in caso di compromissione della chiave del server a lungo termine grazie a PFS.

0-RTT (Zero Round Trip Time) è una funzionalità di TLS 1.3 che consente al client di inviare dati immediatamente insieme a ClientHello durante una connessione ripetuta tramite PSK (Pre-Shared Key). Ciò accelera il caricamento delle schermate successive nelle applicazioni mobili, specialmente con richieste frequenti allo stesso server. Tuttavia, i dati 0-RTT non sono protetti dagli attacchi di replay — possono essere intercettati e reinviati. Utilizzare 0-RTT solo per richieste idempotenti (GET, PUT) senza effetti collaterali.

TLS su iOS: App Transport Security

App Transport Security (ATS) è il meccanismo di Apple che richiede connessioni HTTPS con TLS 1.2 o superiore, attivato per impostazione predefinita da iOS 9. ATS blocca tutte le connessioni HTTP e HTTPS con TLS inferiore a 1.2. Lo sviluppatore può configurare eccezioni in Info.plist tramite NSAppTransportSecurity per domini specifici, ma Apple raccomanda di minimizzare le eccezioni e utilizzare HTTPS ovunque. Violare i requisiti ATS è motivo di rifiuto dell'app durante la revisione dell'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>

Configurazione ATS in Info.plist. NSAllowsArbitraryLoads è impostato su false — tutte le connessioni devono utilizzare HTTPS. Per il dominio cdn.example.com, è specificata una versione minima TLS 1.2, NSAllowsLocalNetworking=true consente HTTP per la rete locale (utile per server di sviluppo). Apple raccomanda vivamente di non attivare NSAllowsArbitraryLoads senza NSExceptionDomains — questa dovrebbe essere un'eccezione, non una regola generale.

TLS su Android: Network Security Config

Network Security Config è il meccanismo di Android per configurare HTTPS e TLS senza modificare il codice Java/Kotlin. La configurazione è specificata nel file network_security_config.xml e collegata in AndroidManifest tramite l'attributo android:networkSecurityConfig. Supporta la configurazione di certificati fidati (CA utente e sistema), Certificate Pinning, disabilitazione di HTTP in chiaro, override di debug e reindirizzamento del traffico.

<!-- 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 per Android. Base-config blocca il traffico in chiaro e si fida solo dei certificati CA di sistema (nessun certificato utente — protezione contro l'installazione di certificati MitM da parte degli utenti). Domain-config per api.example.com contiene un pin-set con un'impronta SHA-256 del certificato. Se il certificato del server cambia prima della data di scadenza specificata, la connessione verrà rifiutata — questa è una forma rigorosa di Certificate Pinning.

Certificate Pinning e sicurezza

Certificate Pinning è una tecnica di fissaggio del certificato o della chiave pubblica del server nel codice dell'applicazione. Durante ogni TLS Handshake, il client confronta il certificato del server con un'impronta precedentemente salvata (hash SHA-256). Anche se un attaccante ottiene un certificato CA fidato o compromette l'autorità di certificazione, non può eseguire un attacco MitM — l'applicazione verifica l'impronta specifica, non la catena CA. Ciò è particolarmente importante per applicazioni finanziarie e app che gestiscono dati sensibili.

Rischi e alternative al Pinning

Certificate Pinning richiede cautela: quando il certificato del server cambia, tutte le versioni precedenti dell'applicazione smetteranno di connettersi. Si consiglia di memorizzare più impronte di backup (principale + backup), specificare una data di scadenza del pin-set e implementare un meccanismo di fallback tramite la verifica CA standard. Un'alternativa è Trust On First Use (TOFU), dove l'applicazione memorizza il certificato al primo collegamento e avvisa l'utente quando cambia. Secondo OWASP (2026), l'assenza di Certificate Pinning rientra tra le prime 3 vulnerabilità delle applicazioni mobili (M3: Comunicazione non sicura).

Implementazione del Pinning in Alamofire

In Alamofire 5+, Certificate Pinning si configura tramite ServerTrustManager con PinnedCertificatesTrustEvaluator (verifica completa del certificato) o PublicKeysTrustEvaluator (solo chiave pubblica). La chiave pubblica è preferibile — non cambia quando il certificato viene rinnovato con la stessa CA. Creare un ServerTrustManager con un dizionario [host: evaluator], passarlo a Session e utilizzarlo per tutte le richieste alle API protette.