Crittografia In Transit

Crittografia In Transit

1) Definizione e limite del controllo

La crittografia in transit è la protezione dei dati su tutto il percorso di trasmissione in rete (browser, server, servizio, agente, broker, database, datacenter) in modo che l'intercettazione passiva e gli attacchi attivi sul canale non rivelino il contenuto e non consentano la modifica senza rilevazione.

Ciò che copriamo sono API pubbliche e private (HTTP/HTTPS, ), streaming e broker (Kafka, NATS, ), database e cache sulla rete, traffico di servizio all'interno dei cluster, VPN/tra-centro e cloud, query DNS, mobile/IoT-client

Ciò che non copriamo completamente sono gli attacchi ai punti finali (compromissione host/browser), le vulnerabilità delle applicazioni, la fuoriuscita da logi/dampi. Questo è risolto dai singoli controlli (A&A, minimizzazione dei diritti, crittografia at rest, loging sicuro).

2) Modello di minacce e obiettivi

Rischi: intercettazione/sostituzione del traffico (MITM), downgrade del protocollo/cifrosuit, certificati/SA contraffatti, fuga di chiavi, attacchi a SNI/metadati, contenuti misti, tergiversazione errata dei TLS sui bilanci, connessioni interserver non sicure.

1. Privacy + integrità con autenticazione crittografica.

2. Opposizione al downgrade (politica rigorosa e config).

3. Identificazione delle parti (server, se necessario).

4. Ciclo di vita gestito di certificati/chiavi e controllo.

5. Profilo delle prestazioni senza compromessi di sicurezza.

3) Principi di base

TLS è ovunque per impostazione predefinita. Traffico esterno e interno - cifrato.
Versioni moderne. TLS 1. 3 come standard; TLS 1. 2 - solo con severi politici. Disattiva 1. 0/1. 1.
Cifrati AEAD con PFS. AES-GCM o ChaCha20-Poly1305; PFS tramite (CE) DHE.
Curve/k-exchange. X25519 (preferibilmente) o secp256r1 (P-256). Chiavi RSA ≥2048, meglio di ECDSA (P-256).
mTLS dove la fiducia è scarsa. Canali interserver, admine-API, broker, basi - attraverso l'autenticazione reciproca.
HSTS per il web. Obbligatorio HTTPS + proload per domini pubblici.
Cifrando e cifrando in modo consapevole. Terminazione TLS su perimetro + crittografia fino a backend o passthrough end - Seleziona in base al modello di minaccia.
Crypto-agility. Possibilità di modificare curve/suit/versioni a zero inattività.

4) Stack di protocolli e script

4. 1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN: h2 per HTTP/2, h3 per HTTP/3; Divieto h2c (senza TLS).
HTTP/3/QUIC: riduce la latitudine, lo 0-RTT incorporato e la migrazione delle connessioni 0-RTT per consentire selettivamente (rischio di replica).
gRPC: sopra h2/h3; TLS obbligatorio, abilitazione opzionale + per-RPC.
WebSocket: solo wss ://; nei proxy/bilanciatori è un upgrade corretto e un pinning di dominio TLS.

4. 2 Interscambio e servizio-fastidio

Modello Sidecar (Istio/Linkerd, ecc.). mTLS automatico, regole di risoluzione, rotazione dei certificati.
SPIFFE/SPIRE. Identità decentralizzata dei servizi (SPIFFE ID), certificati SVID, TTL brevi.
Le impostazioni TLS vengono centralizzate. Minimizza l'eterogeneità delle configurazioni nel codice dei servizi.

4. 3 Broker/streaming/code

Kafka/NATS/RabbitMQ: TLS per kliyent↔broker e broker↔broker; Se possibile, mTLS.
SASL sopra TLS - Se mTLS non è possibile, l'autenticazione è per token/login, ma il canale è cifrato.
ACL e autorizzazioni dei temi. Crittografia, controllo di accesso.

4. 4 Database e cache

PostgreSQL/MySQL/SQL Server: abilita TLS, convalida CN/SAN, pin SA/radice.
Redis/Memcached: usa stunnel/TLS-redis; divieto di traffico plain in vendita.

4. 5 Rete/tunnel

Tra centro dati/nuvole: IPsec (IKEv2) o WireGuard (insieme moderno di primitivi).
Accesso Admin: SSH con KEH e codici moderni; proibizione delle password, solo chiavi/SSO.

4. 6 DNS e protocolli di supporto

DNS over HTTPS (DoH )/DNS over TLS (DoT) per i clienti e all'interno del cluster, ove possibile.
Disattiva i contenuti misti. Niente per http ://nelle pagine https ://.

5) Certificati, PKI e gestione delle chiavi

Modello PKI per domini esterni - CA pubblico per il traffico interno, il proprio CA o SPIRE-CA.
Automazione: ACME/Cert-Manager per Kubernets, TTL brevi, rotazione automatica.
OCSP stapling и CRL. Abilita stapling sui fronti Aggiorna regolarmente le catene.
Pinning, con cautela. Nei client mobile/disctop - pin CA/SPKI con motore di rilevamento di emergenza.
Archiviazione delle chiavi: chiavi private in HSM/KMS/Secret Storage; Minime esposizioni Divieto di loging.

6) Configurazioni: profili pratici

• Versione TLS 1. 3 (obbligatorio), TLS 1. 2 (fallback).

• TLS 1. 3: `TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
• TLS 1. 2: 'ECDHE-ECDSA-AES128-GCM-SHA256', 'ECDHE-RSA-AES128-GCM-SHA256' (+ opzioni AES256/CHACHA20 se necessario).
• Curve: X25519, secp256r1.
• Certificati ECDSA-preferibilmente, RSA-fallback.
• Intestazioni sicure: «Strict-Transfer-Security», «X-Content-Type-Options», «X-Frame-Options», «Referrer-Policy».
• Cookies: «Secure», «HttpOnly», «SameSite» (Lax/Strict Design).

• Il certificato client è obbligatorio.
• TTL brevi SVID client (ore/giorni), rotazione automatica.
• Criteri: chi può connettersi a chi (intent-based/lavoro tramite l'autorizzazione mesh).

7) Prestazioni e affidabilità

Accelerazione hardware: AES-NI/ARMv8 Crypto, preferenza per CPU senza AES-NI.
Session resumption: TLS 1. 3 tickets; Pensare alla durata della vita (equilibrio tra perf e sicurezza).
0-RTT - Solo per richieste idipotenti proteggersi dalle repliche (meccanismi anti-replay per server).
Bilanciatori/proxy: scegliere chiaramente termination vs passthrough; termination - re-cifrare al backend.
Osservabilità: metriche di strette di mano/errori/negoziazioni ALPN, percentuale TLS 1. 3, certificati scaduti, stato OCSP.

8) Test e verifica

Scansione del profilo TLS. Controlli regolari delle versioni supportate/suit/curve e HSTS/OCSP.
Test negativi: divieto di downgrade, rifiuto dei suit deboli, interruzione delle connessioni senza SNI/senza certificato di catena valida.
Pentest canale: simulazioni MITM, verifica del pinning nei client mobili, tentativi di replica 0-RTT.
Test Chaos: decadenza/revoca del certificato, indisponibilità OCSP/CA.

9) Errori frequenti e come evitarli

TLS attivato, ma senza convalida host. Controlliamo sempre CN/SAN, vietiamo «InsecureSkipVerify».
Contenuti misti. Bloccare le risorse http nelle pagine https, utilizzare il CSP.
Versioni deboli/obsolete e suit. Disattiva TLS 1. 0/1. 1, CBC/RC4/3DES.
Nessuna e-crittografia all'interno. Il traffico plain da bilanciatore a applicazione è un rischio.
Certificati a lunga vita. Effettuare brevi aggiornamenti TTL e auto.
SNI/ALPN non valido per il proxy. Trasmissione SNI/ALPN corretta a TLS-passs-tru/terminazione.

10) Mini-ricette (porzioni di configurazione)

ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11) Criteri e conformità

Requisiti minimi: TLS 1. 3 ovunque possibile; TLS 1. 2 - con un insieme limitato di suit.
Regolatore: PCI DSS/finsettore - Proibire versioni deboli/suit; rotazione e controllo obbligatori.
Approccio zero trust: identità per ogni carico di lavoro, controllo continuo e regole a livello di servizio.

12) Utilizzo e SLO

SLO: ≥99% di strette di mano di successo, ≥95% di traffico su TLS 1. 3, 0% di contenuti misti.
Alert: cadenza dei certificati (<14 giorni), aumento dei rigori delle strette di mano, calo della quota di TLS 1. 3, errori OCSP stapling.
Procedure: sostituzione di emergenza A/radice, revoca della chiave compromessa, disattivazione 0-RTT.

13) Assegno fogli

• TLS 1 è disattivato. 0/1. 1 e i suit deboli inclusi AEAD e PFS.
• ALPN configurato (h2/h3); Divieto h2c.
• HSTS abilitato (per domini pubblici), mixed content mancante.
• I certificati auto sono aggiornati, OCSP stapling in esecuzione.
• I canali interni sono protetti (o l'equivalente di un ).
• Convalida degli host/catene nei client/SDK verificata.

• Monitoraggio delle versioni TLS/ALPN/errori ed esportazioni.
• Piano crypto-agility (tradotto in nuovi suit/curve).
• Pentestri periodici del canale e ringhiera di conferme.

14) FAQ

La TLS è sufficiente solo nel perimetro?
Oh, no. Anche il traffico interno deve essere crittografato (mTLS/tunnel/mesh), soprattutto nelle nuvole e in caso di polivalenza.

C: È necessario 0-RTT?
O: Attivare i punti per le richieste Idempotent, altrimenti disattivare a causa del rischio di repliche.

C: Cosa scegliere per il centro dati? IPSEC o WireGuard?
WireGuard più semplice e veloce, IPsec - maturo e molto supportato. Entrambi validi se configurati correttamente.

Come si proteggono i webhook'in viaggio '?
O: HTTPS con profilo avanzato + convalida del certificato del mittente (se mTLS) + firma del carico utile e verifica del timestream (vedere Garanzie di spedizione Web, Firma e convalida delle richieste).

• Crittografia At Rest'
• Autenticazione e autorizzazione
• Firma e verifica query
• Autenticazione S2S
• Gestione e rotazione delle chiavi