HTTP/HTTPS: cosa sono, protocolli di trasferimento dati e crittografia TLS

Cosa sono HTTP e HTTPS?

HTTP (HyperText Transfer Protocol) è un protocollo a livello applicativo del modello OSI progettato per trasferire documenti ipertestuali e altri dati sul World Wide Web. Sviluppato da Tim Berners-Lee nel 1989, HTTP ha attraversato diverse versioni: da HTTP/0.9 (solo richieste GET e risposte HTML) ai moderni HTTP/2 e HTTP/3. Il protocollo opera secondo il modello richiesta-risposta: il client invia una richiesta al server, il server la elabora e restituisce una risposta.

HTTPS (HTTP Secure) è un'estensione del protocollo HTTP che aggiunge un livello di crittografia tramite TLS (Transport Layer Security). HTTPS non è un protocollo separato — è una combinazione di HTTP e TLS. I dati trasmessi tramite HTTPS vengono crittografati lato client e decrittografati sul server, rendendoli inaccessibili a intercettazioni e manomissioni. HTTPS fornisce anche l'autenticazione del server tramite certificati SSL/TLS, garantendo che il client si connetta al server reale e non a un aggressore.

La differenza principale tra HTTP e HTTPS è la sicurezza. HTTP trasmette i dati in chiaro: qualsiasi nodo di rete tra client e server può leggere il contenuto di una richiesta o risposta. HTTPS crittografa tutto il contenuto, inclusi URL, intestazioni e corpo della richiesta, lasciando visibili solo l'indirizzo IP del server e la porta di connessione. Per le applicazioni mobili che operano su reti Wi-Fi pubbliche, HTTPS è un requisito di sicurezza obbligatorio.

Come funziona HTTP

HTTP è un protocollo senza stato (stateless) che opera su TCP/IP. Il client stabilisce una connessione TCP con il server (di solito sulla porta 80 per HTTP o 443 per HTTPS), invia una richiesta HTTP, riceve una risposta HTTP e chiude la connessione (in HTTP/1.1 la connessione può essere riutilizzata). Ogni interazione tra client e server consiste in una richiesta e una risposta. L'assenza di stato significa che il server non memorizza informazioni sulle richieste precedenti del client — ogni richiesta viene elaborata in modo indipendente.

Il processo di interazione HTTP include i seguenti passaggi:

• Risoluzione DNS — il browser o il client risolve il nome di dominio in un indirizzo IP tramite DNS
• Handshake TCP — viene stabilita una connessione TCP tramite un handshake a tre fasi (SYN, SYN-ACK, ACK)
• Handshake TLS — per HTTPS, viene inoltre stabilita una connessione crittografata (scambio di certificati e chiavi)
• Richiesta HTTP — il client invia il metodo, URL, intestazioni e opzionalmente il corpo della richiesta
• Risposta HTTP — il server restituisce un codice di stato, intestazioni e corpo della risposta

Una caratteristica importante di HTTP è l'idempotenza dei metodi. GET, HEAD, PUT, DELETE e OPTIONS sono idempotenti: l'esecuzione ripetuta della stessa richiesta non modifica lo stato del server dopo la prima esecuzione. POST, PATCH e CONNECT non sono idempotenti — ogni chiamata può creare una nuova risorsa o modificare lo stato. Per lo sviluppo mobile, comprendere l'idempotenza è fondamentale: quando si reinvia una richiesta a causa di un errore di rete, il client deve sapere se è sicuro ripetere la richiesta.

HTTPS e crittografia TLS

HTTPS utilizza il protocollo crittografico TLS (Transport Layer Security) per proteggere i dati trasmessi. TLS è il successore di SSL (Secure Sockets Layer), sviluppato da Netscape nel 1995. Le versioni SSL 2.0 e 3.0 sono considerate obsolete e non sicure; le versioni moderne TLS 1.2 (rilasciata nel 2008) e TLS 1.3 (rilasciata nel 2018) sono utilizzate ovunque. TLS 1.3, in particolare, riduce il tempo di stabilimento della connessione da 2 round-trip a 1, accelerando significativamente il caricamento sui dispositivi mobili.

Il processo di handshake TLS include le seguenti fasi:

• Client Hello — il client invia un elenco delle versioni TLS e delle suite di cifratura supportate
• Server Hello — il server seleziona la versione TLS e la suite di cifratura, invia il suo certificato SSL/TLS
• Verifica del certificato — il client verifica il certificato del server attraverso una catena di fiducia fino alla CA radice
• Scambio di chiavi — il client e il server generano una chiave segreta condivisa (chiave di sessione)
• Cambio di cifratura — entrambe le parti confermano il passaggio alla comunicazione crittografata

La verifica del certificato SSL/TLS è un passaggio critico per la sicurezza. Il client controlla che il certificato: non sia scaduto, sia firmato da un'autorità di certificazione (CA) attendibile, corrisponda al dominio nell'URL e non sia stato revocato (tramite CRL o OCSP). Nelle applicazioni mobili, si raccomanda di utilizzare Certificate Pinning — il vincolo a un certificato specifico del server o chiave pubblica. Ciò previene gli attacchi MITM anche in caso di compromissione di una CA. Tuttavia, il pinning richiede cautela: quando il certificato cambia, l'applicazione deve essere aggiornata preventivamente.

Struttura di richiesta e risposta HTTP

Una richiesta HTTP è composta da tre parti: la riga di richiesta, le intestazioni e un corpo opzionale. La riga di richiesta contiene il metodo HTTP, l'URL della richiesta e la versione HTTP. Le intestazioni trasmettono meta-informazioni: tipo di contenuto, token di autenticazione, impostazioni di caching. Il corpo è presente solo nei metodi che trasmettono dati (POST, PUT, PATCH) ed è assente in GET e DELETE.

Esempio di richiesta HTTP a un'API REST:

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

Una risposta HTTP ha una struttura simile: una riga di stato con la versione HTTP e il codice di stato, intestazioni e corpo. Il codice di stato è un numero a tre cifre che determina il risultato dell'elaborazione della richiesta. Le intestazioni di risposta includono Content-Type, Content-Length, Cache-Control, Set-Cookie e altre. Il corpo della risposta contiene i dati richiesti nel formato specificato in Content-Type (di solito JSON per le API, HTML per le pagine web, immagini per i contenuti multimediali).

Le intestazioni svolgono un ruolo critico nel funzionamento di HTTP. Content-Type e Accept controllano il formato dei dati. Authorization trasmette i token di accesso. Cache-Control gestisce la memorizzazione nella cache. Le intestazioni CORS (Access-Control-Allow-Origin) controllano l'accesso da altri domini nei browser. User-Agent identifica l'applicazione client. Per le applicazioni mobili, le intestazioni di controllo della cache sono particolarmente importanti — aiutano a ridurre la quantità di dati trasmessi e migliorano le prestazioni su segnale debole.

Codici di stato HTTP

I codici di stato HTTP sono raggruppati in cinque classi, indicate dalla prima cifra: 1xx (informativo), 2xx (successo), 3xx (reindirizzamento), 4xx (errore del client), 5xx (errore del server). Comprendere questi codici è necessario per gestire correttamente le risposte in un'applicazione mobile: 2xx significa successo e i dati possono essere visualizzati, 4xx indica un problema nella richiesta (mostrare un errore all'utente), 5xx indica un problema del server (riprovare più tardi).

Per le applicazioni mobili, la gestione del codice 401 Unauthorized è particolarmente importante. Al ricevimento di questo codice, il client dovrebbe tentare di aggiornare il token di accesso tramite un Refresh Token e ripetere la richiesta originale. Se anche l'aggiornamento del token restituisce 401, l'utente deve essere reindirizzato alla schermata di login. Questa logica è solitamente implementata in un Interceptor (OkHttp) o nel livello middleware del client di rete.

HTTP/1.1, HTTP/2 e HTTP/3

HTTP/1.1, pubblicato nel 1999, è ancora una versione ampiamente utilizzata del protocollo. Il suo principale svantaggio è l'head-of-line blocking: le richieste allo stesso server vengono eseguite in sequenza, ciascuna attende il completamento della precedente. Per aggirare questa limitazione, i browser aprono 6-8 connessioni TCP parallele allo stesso dominio, aumentando il carico del server e il consumo di memoria. HTTP/1.1 trasmette anche le intestazioni in chiaro e non supporta il server push.

HTTP/2 (2015) risolve il problema del blocco attraverso il multiplexing — più flussi di dati vengono trasmessi simultaneamente su un'unica connessione TCP. Il server può inviare risorse al client prima che il client le richieda (server push). HTTP/2 comprime anche le intestazioni tramite HPACK, riducendo la quantità di dati trasmessi. Per le applicazioni mobili, HTTP/2 è particolarmente utile: una connessione sostituisce diverse, riducendo il tempo di handshake TLS e il consumo della batteria.

HTTP/3 (2022) è l'ultima versione del protocollo, che utilizza QUIC (Quick UDP Internet Connections) invece di TCP. QUIC opera su UDP, eliminando il problema dell'head-of-line blocking a livello del protocollo di trasporto. HTTP/3 riduce il tempo di stabilimento della connessione a 0 round-trip nel migliore dei casi (su connessioni ripetute) e a 1 round-trip alla prima connessione, risultando significativamente più veloce di HTTP/2 con i suoi 2-3 round-trip. Per i dispositivi mobili, HTTP/3 è particolarmente efficace quando si passa tra Wi-Fi e reti mobili — la connessione non viene interrotta perché QUIC utilizza un identificatore di connessione anziché un indirizzo IP.

HTTPS nello sviluppo mobile

L'uso di HTTPS nelle applicazioni mobili non è una raccomandazione ma un requisito obbligatorio. A partire da Android 9 (API 28) e iOS 9 (ATS — App Transport Security), tutte le richieste di rete devono utilizzare HTTPS per impostazione predefinita. Le richieste HTTP vengono bloccate dal sistema e per consentirle è necessaria un'eccezione esplicita nella configurazione dell'applicazione. Google Play Store e App Store rifiutano le applicazioni che trasmettono dati sensibili tramite HTTP, inclusi password, token e dati personali.

La configurazione HTTPS in un'applicazione Android include:

<!-- AndroidManifest.xml — autorizzazione richiesta di rete -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — configurazione 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>

Su iOS, una configurazione simile viene eseguita tramite Info.plist con la chiave NSAppTransportSecurity. Per eseguire il debug del traffico HTTPS nelle applicazioni mobili, vengono utilizzati strumenti proxy: Charles Proxy, Proxyman o mitmproxy. Richiedono l'installazione di un certificato SSL attendibile sul dispositivo. Nelle build di produzione, le capacità di debug devono essere disabilitate e il Certificate Pinning deve essere verificato come configurato correttamente. L'uso di OkHttp su Android con il suo CertificatePinner o TrustManager su iOS con SecTrustEvaluate sono approcci standard per implementare il pinning.

Un aspetto importante della sicurezza HTTPS nello sviluppo mobile è l'SSL Pinning. Senza pinning, l'applicazione si fida di qualsiasi certificato firmato da una CA nota. Se la CA viene compromessa, un aggressore potrebbe intercettare il traffico dell'applicazione. Il pinning vincola l'applicazione a un certificato specifico del server o chiave pubblica. Quando il certificato del server cambia, deve essere rilasciato un aggiornamento dell'applicazione, quindi il pinning viene pianificato con un margine — vincolo a un certificato CA superiore o utilizzo di più chiavi di backup.