Ottimizzare TLS e HTTPS su Nginx: ridurre TTFB e latenza

TLS su Nginx: perché il tuning fa la differenza su HTTPS

Quando si parla di prestazioni web, l’ottimizzazione del TLS è spesso trascurata in favore di interventi più vistosi come la cache applicativa o l’indicizzazione del database. Eppure, su un server Nginx esposto in HTTPS, ogni handshake TLS non ottimizzato aggiunge latenza misurabile a ogni connessione nuova. Questa guida raccoglie le configurazioni che un sistemista esperto dovrebbe avere presenti per tenere basso il TTFB (Time To First Byte) e ridurre l’overhead delle connessioni sicure.

Una premessa importante: il tuning TLS non salva un’applicazione lenta. Se la generazione della pagina richiede 800ms, ottimizzare il TLS porterà al massimo qualche decina di millisecondi in meno. Il vero valore di queste configurazioni emerge su backend già veloci, dove l’overhead del protocollo diventa la variabile dominante.

TLS 1.2 o TLS 1.3: quale usare?

Dal 30 giugno 2018 il PCI Security Standards Council richiede la disabilitazione di SSL 3.0, TLS 1.0 e TLS 1.1. Ad oggi, la configurazione raccomandata è supportare esclusivamente TLS 1.2 e TLS 1.3:

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 è decisamente preferibile: riduce il numero di round-trip necessari per il handshake (da 2 a 1) e rimuove algoritmi di cifratura obsoleti. Se il target è esclusivamente moderno (browser aggiornati, client API recenti), si può anche forzare solo TLS 1.3:

ssl_protocols TLSv1.3;

Tuttavia, TLS 1.2 rimane necessario per compatibilità con client enterprise, dispositivi embedded e alcune librerie legacy. Per la maggior parte dei server in produzione, supportare entrambi è la scelta più pragmatica.

Abilitare HTTP/2 e HTTP/3 (QUIC)

HTTP/2 è diventato lo standard de facto e Nginx lo supporta nativamente. Dalla versione 1.25.1, la direttiva è cambiata: non va più in listen ma come direttiva separata nel blocco server:

listen 443 ssl;
http2 on;

Per chi vuole spingersi a HTTP/3 con QUIC (disponibile nei pacchetti Nginx mainline compilati con BoringSSL o quic-go), la configurazione si estende così:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    http2 on;

    ssl_certificate     /path/to/your/certificate.pem;
    ssl_certificate_key /path/to/your/key.pem;

    # Comunica al client il supporto HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Per verificare quale protocollo viene negoziato dal lato command-line:

# Verifica HTTP/2
curl --http2 -I https://tuo-dominio.com/

# Verifica HTTP/3
curl --http3 -I https://tuo-dominio.com/

Session cache e session tickets: differenze chiave

La session cache lato server permette di riutilizzare i parametri crittografici di una sessione TLS precedente, evitando il full handshake per connessioni successive dello stesso client. In Nginx si configura così:

ssl_session_cache shared:SSL:10m;  # ~40.000 sessioni per MB
ssl_session_timeout 1d;

I session tickets sono un meccanismo alternativo: invece di conservare lo stato sul server, il server cifra i parametri della sessione e li invia al client, che li ripresenta alla connessione successiva. Questo elimina lo stato server-side ma introduce rischi se la chiave di cifratura dei ticket viene compromessa (forward secrecy ridotta). La raccomandazione per ambienti ad alta sicurezza è disabilitarli:

ssl_session_tickets off;

Nella pratica, su infrastrutture con bilanciamento del carico senza sticky sessions, i ticket sono spesso l’unico modo per ottenere session resumption tra istanze diverse. Valutare caso per caso.

OCSP Stapling: eliminare la latenza di validazione del certificato

Senza OCSP Stapling, ogni nuovo client deve contattare la CA (Certificate Authority) per verificare che il certificato non sia stato revocato. Questo aggiunge una richiesta di rete esterna al percorso critico dell’handshake. Con lo stapling, è Nginx stesso a interrogare periodicamente la CA e a includere la risposta firmata direttamente nell’handshake TLS:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Il parametro ssl_trusted_certificate deve puntare alla catena completa (root CA inclusa), non solo al certificato del server. Il resolver è necessario perché Nginx deve risolvere l’hostname della CA tramite DNS.

Ridurre ssl_buffer_size

Il valore predefinito di ssl_buffer_size in Nginx è 16KB, dimensionato per throughput massimo. Questo significa però che il primo byte del payload arriva al client solo dopo che il primo chunk da 16KB è stato riempito e cifrato. Per siti dove il TTFB è critico (landing page, API), ridurre il buffer abbassa la latenza percepita:

ssl_buffer_size 4k;

Sul throughput per file di grandi dimensioni (video, download) questo valore è subottimale; per contenuto testuale e API è quasi sempre vantaggioso.

Configurazione completa raccomandata

Di seguito la configurazione consolidata che integra tutti i punti trattati, da inserire nel blocco http o nel blocco server di Nginx:

http2 on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_buffer_size 4k;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Dopo ogni modifica, verificare la sintassi e ricaricare:

nginx -t
nginx -s reload

HSTS: forzare HTTPS a livello di browser

HTTP Strict Transport Security istruisce i browser a non tentare mai connessioni HTTP plain verso il dominio, riducendo anche la superficie d’attacco da downgrade. L’intestazione si aggiunge così:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Il valore max-age è in secondi: 63072000 corrisponde a due anni, il minimo richiesto per l’inserimento nel preload list di Chrome. Prima di abilitare includeSubDomains, verificare che tutti i sottodomini siano effettivamente raggiungibili in HTTPS.

Conclusione

Il tuning TLS su Nginx non è un’operazione una tantum ma una configurazione che vale la pena standardizzare nei propri template di deployment. HTTP/2 abilitato, session cache attiva, OCSP Stapling e buffer ridotto sono quattro interventi a costo zero che si traducono in un’esperienza più reattiva per l’utente finale e in una postura di sicurezza più moderna. Per ambienti con requisiti di latenza estrema o traffico prevalentemente mobile, HTTP/3 con QUIC rappresenta il passo successivo logico, anche se richiede una build di Nginx con supporto esplicito.

Fonte originale: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency – linuxblog.io