TLS HTTPS — Cheat Sheet

Tag: tls, https, ssl, cryptography, networking, security, web

Livello: intermedio

TL;DR: HTTPS incapsula HTTP su un canale cifrato TLS per garantire riservatezza, integrità e autenticazione tra client e server tramite crittografia asimmetrica e simmetrica.

Concetti chiave

-

HTTPS opera sulla porta standard 443 incapsulando il traffico HTTP applicativo all'interno di una sessione TLS cifrata.

-

I tre pilastri di TLS sono crittografia (riservatezza dei dati), integrità (rilevamento manomissioni con MAC/AEAD) e autenticazione del server.

-

L'handshake TLS stabilisce parametri crittografici e negozia una chiave simmetrica condivisa (chiave di sessione).

-

La crittografia asimmetrica (RSA, ECDHE) protegge la fase iniziale di scambio chiavi e verifica dell'identità.

-

La crittografia simmetrica (AES-GCM, ChaCha20-Poly1305) cifra il flusso reale dei dati con overhead ridotto.

-

Il certificato digitale X.509 lega la chiave pubblica del server al suo dominio, firmato da una Certificate Authority riconosciuta.

-

SNI (Server Name Indication) invia l'hostname in chiaro nel Client Hello per consentire il virtual hosting su singolo IP.

-

TLS 1.3 riduce la latenza di negoziazione a un solo round-trip (1-RTT) eliminando cipher suite obsolete.

-

TLS 1.3 supporta la modalità 0-RTT (Early Data) per connessioni successive verso server già visitati.

-

ALPN (Application-Layer Protocol Negotiation) negozia il protocollo applicativo (es. HTTP/2 o HTTP/1.1) durante l'handshake TLS.

Domande tipiche e risposte pronte

-

Q: Qual è la differenza strutturale principale tra TLS 1.2 e TLS 1.3?R: TLS 1.3 riduce l'handshake standard da 2-RTT a 1-RTT, rimuove cipher suite e algoritmi non sicuri come RSA puro per lo scambio chiavi o CBC, e forza la Perfect Forward Secrecy tramite ECDHE effimero.

-

Q: Cos'è la Perfect Forward Secrecy (PFS) e come protegge le sessioni?R: La PFS genera chiavi di sessione temporanee effimere per ogni connessione. Anche se la chiave privata a lungo termine del server viene compromessa in futuro, il traffico registrato in precedenza non può essere decifrato.

-

Q: Come valida il browser la catena di certificati ricevuta dal server?R: Il browser verifica la firma digitale risalendo dai certificati intermedi fino al certificato radice attendibile presente nel proprio trust store locale, controllando date di validità, SAN/dominio e revoche (CRL/OCSP).

-

Q: Perché si usa la crittografia asimmetrica solo durante l'handshake e non per trasmettere i payload?R: Gli algoritmi asimmetrici richiedono un carico computazionale troppo elevato per grandi volumi di dati, quindi li uso solo per autenticare e scambiare le chiavi simmetriche, molto più veloci.

-

Q: Cos'è HSTS e quale vulnerabilità previene?R: È un header di sicurezza HTTP che obbliga il browser a utilizzare sempre HTTPS per le richieste future, mitigando gli attacchi di SSL stripping o downgrade su reti insicure.

Insidie e errori comuni

-

Dimenticare di configurare il redirect HTTP 301 verso HTTPS lasciando le richieste su porta 80 non protette.

-

Omettere l'inclusione dei certificati intermedi (full chain) nella configurazione del web server, rompendo la fiducia sui client mobili.

-

Ignorare la vulnerabilità a replay attack intrinseca nella funzionalità 0-RTT di TLS 1.3 su richieste POST non idempotenti.

-

Confondere la crittografia dei dati con l'integrità del payload a livello applicativo o l'autenticazione utente.

-

Utilizzare cipher suite obsolete abilitando protocolli ritirati come SSLv3, TLS 1.0 o TLS 1.1.

Snippet e comandi

# Ispezione completa del certificato remoto e catena TLS
openssl s_client -connect api.example.com:443 -servername api.example.com

# Verifica scadenza e subject di un certificato X.509 locale
openssl x509 -in cert.pem -noout -subject -dates

# Test dei protocolli supportati e cipher suite con testssl.sh
testssl.sh -p --protocols api.example.com:443

Nginx

# Configurazione moderna Nginx per TLS 1.2 e 1.3 con HSTS
server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5:!3DES;
    ssl_prefer_server_ciphers on;

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

Da ripassare

-

[ ] Sequenza dettagliata dei messaggi dell'handshake TLS 1.3 rispetto a TLS 1.2

-

[ ] Meccanismi di verifica revoca tramite OCSP Stapling

-

[ ] Configurazione corretta dell'estensione SNI su reverse proxy Nginx o Traefik

-

[x] Ruolo della chiave pubblica e privata nella firma digitale e nello scambio dati

Jarvis Interviews
Jarvis