Cryptage In Transit

Cryptage In Transit

1) Définition et limites des contrôles

La cryptographie in transit est une protection des données sur toute la voie de la transmission de réseau (le navigateur ↔ le serveur, le service ↔ le service, l'agent ↔ le broker, la base ↔ l'application, датацентр ↔ датацентр) pour que l'interception passive et les attaques actives contre le canal ne découvrent pas le contenu et ne le permettaient pas de modifier sans détection.

Ce que nous couvrons : API publiques et privées (HTTP/HTTPS, gRPC), streaming et courtiers (Kafka, NATS, RabbitMQ), WebSocket, bases et caches sur le réseau, trafic de service à l'intérieur des clusters, VPN/entre les centres et les nuages, demandes DNS, Mobile/Mobile Clients IoT.

Ce que nous ne couvrons pas entièrement : attaques sur les points de terminaison (compromission de l'hôte/navigateur), vulnérabilités des applications, fuites des logs/vides. Cela est résolu par des contrôles distincts (A&A, minimisation des droits, cryptage à rest, logging sécurisé).

2) Modèle de menace et objectifs

Risques : interception/échange de trafic (MITM), downgrade de protocole/cryptage, faux certificats/AC, fuite de clés, attaques SNI/métadonnées, contenu mixte, termination TLS incorrecte sur les équilibres, connexions interservices dangereuses.

1. Confidentialité + intégrité avec authentification cryptographique.

2. L'opposition au downgreid (politique stricte et config).

3. Identification des parties (serveur, si nécessaire réciproque).

4. Gestion du cycle de vie des certificats/clés et audit.

5. Profil de performance sans compromis de sécurité.

3) Principes de base

TLS est partout par défaut. Trafic externe et interne - cryptage.
Les versions modernes. TLS 1. 3 en tant que norme ; TLS 1. 2 - seulement avec des politiques strictes. Désactiver 1. 0/1. 1.
Les chiffreurs AEAD avec PFS. AES-GCM ou ChaCha20-Poly1305 ; PFS via (EC) DHE.
Courbes/kay-exchange. X25519 (de préférence) ou secp256r1 (P-256). Les clés RSA sont ≥2048, mieux que l'ECDSA (P-256).
mTLS là où la confiance est faible. Canaux interservices, API admin, courtiers, bases - via l'authentification mutuelle.
HSTS pour le web. Forcer HTTPS + preload pour les domaines publics.
« Cryptage-et-ré-cryptage » consciemment. Terminaison TLS sur le périmètre + ré-encryptage jusqu'aux backends ou passthrough de bout en bout - nous sélectionnons par modèle de menace.
Crypto-agility. Possibilité de modifier les courbes/suits/versions sans interruption.

4) Pile de protocoles et scripts

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

ALPN : h2 pour les HTTP/2, h3 pour les HTTP/3 ; interdiction de h2c (sans TLS).
HTTP/3/QUIC : réduit la latence, les 0-RTT intégrés et la migration des connexions ; 0-RTT autoriser de manière sélective (risque de repli).
gRPC : sur h2/h3 ; obligatoirement TLS, en option mTLS + autorisation per-RPC.
WebSocket : seulement wss ://; dans les proxy/balancers - mise à niveau correcte et pinning de domaine TLS.

4. 2 Trafic et services interservices

Modèle Sidecar (Istio/Linkerd, etc.). MTLS automatique, règles d'autorisation, rotation des certificats.
SPIFFE/SPIRE. Identités décentralisées des services (SPIFFE ID), certificats S...., TTL courts.
Les paramètres TLS sont centralisés. Minimiser la diversité des configues dans le code des services.

4. 3 Courtiers/streaming/files d'attente

Kafka/NATS/RabbitMQ : TLS pour les kliyent↔broker et les broker↔broker ; si possible, mTLS.
SASL au-dessus de TLS : Si mTLS n'est pas possible, l'authentification est par tokens/logins, mais le canal est crypté.
ACL et autorisation des sujets. Cryptage ≠ contrôle d'accès.

4. 4 Bases de données et caches

PostgreSQL/MySQL/SQL Server : activer TLS, validation CN/SAN, pin SA/racine.
Redis/Memcached : utiliser des radis stunnel/TLS ; interdiction du trafic de plain-pied dans la vente.

4. 5 Réseau/tunnels

Entre les centres de données/nuages : IPsec (IKEv2) ou WireGuard (ensemble moderne de primitives).
Admin-access : SSH avec des CEH/codes modernes ; interdiction des mots de passe, clés/SSO uniquement.

4. 6 DNS et protocoles auxiliaires

DNS over HTTPS (DoH )/DNS over TLS (DoT) pour les clients et au sein du cluster si possible.
Désactiver le contenu mixte. Rien sur http ://sur les pages https ://.

5) Certificats, PKI et gestion des clés

Modèle PKI : pour les domaines externes - AC publics ; pour le trafic intérieur - votre propre CA ou SPIRE-CA.
Automatisation : ACME/Cert-Manager pour Kubernetes, TTL courts, auto-rotation.
OCSP stapling и CRL. Activer le stapling sur les fronts ; mettre à jour régulièrement les chaînes.
Pinning - avec prudence. Dans les clients mobiles/de bureau - pin CA/SPKI avec mécanisme de roulement d'urgence.
Stockage des clés : clés privées dans les entrepôts HSM/KMS/secret ; un minimum d'expositions ; interdiction de loger.

6) Configurations : Profils pratiques

• Versions : TLS 1. 3 (obligatoire), 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' (+ options AES256/CHACHA20 si nécessaire).
• Courbes : X25519, secp256r1.
• Certificats : ECDSA-de préférence, RSA-fallback.
• Titres sécurisés : 'Strict-Transport-Security', 'X-Content-Type-Options', 'X-Frame-Options', 'Referrer-Policy'.
• Cookies : 'Secure', 'HttpOnly', 'SameSite' (Lax/Strict par conception).

• Le certificat client est obligatoire.
• TTL court du client S....( heures/jours), rotation automatique.
• Politiques : qui peut se connecter à qui (intent-based/travail via mesh-autorisation).

7) Performance et fiabilité

Accélération matérielle : AES-NI/ARMv8 Crypto, préférence de ChaCha20-Poly1305 sur un CPU sans AES-NI.
Session resumption: TLS 1. 3 tickets; réfléchir à la durée de vie (équilibre entre la perfusion et la sécurité).
0-RTT : uniquement pour les demandes idempotentes ; Protégez-vous contre le replay (les mécanismes anti-replay du serveur).
Balancers/proxy : choisir clairement la terminaison vs passthrough ; lors de la terminaison, ré-encrypter vers le backend.
Observation : Mesures des poignées de main/erreurs/négociations ALPN, pourcentage TLS 1. 3, expiration des certificats, statut OCSP.

8) Test et vérification

Scan du profil TLS. Vérifiez régulièrement les versions prises en charge/suits/courbes et HSTS/OCSP.
Tests négatifs : interdiction de downgrade, déviation des suites faibles, défaillance des connexions sans SNI/sans certificat de chaîne validé.
Pentest du canal : simulation MITM, vérification du pinning dans les clients mobiles, tentatives de relais 0-RTT.
Tests Chaos : expiration/retrait du certificat, indisponibilité de l'OCSP/CA.

9) Erreurs fréquentes et comment les éviter

TLS est activé, mais pas de validation d'hôte. Toujours vérifier CN/SAN, interdire 'InsecureSkipVerify'.
Contenu mixte. Bloquez les ressources http sur les pages https, utilisez CSP.
Versions faibles/obsolètes et suites. Désactiver TLS 1. 0/1. 1, CBC/RC4/3DES.
Pas de cryptage interne. Le trafic de plain-pied de l'équilibreur à l'application est un risque.
Certificats de longue durée. Faites une courte TTL et auto-mise à jour.
SNI/ALPN incorrect pour le proxy. Transfert SNI/ALPN correct dans le pass/terminaison TLS.

10) Mini recettes (fragments de configurations)

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) Politiques et conformité

Exigences minimales : TLS 1. 3 partout où c'est possible ; TLS 1. 2 - avec un ensemble limité de suites.
Réglementation : PCI DSS/finsecteur - interdiction des versions faibles/suites ; rotation obligatoire et audit.
Approche Zero Trust : identités pour chaque charge de travail, vérification continue et politique au niveau du service.

12) Fonctionnement et SLO

SLO : ≥99 % des poignées de main réussies, ≥95 % du trafic sur TLS 1. 3, 0 % de contenu mixte.
Alert : expiration des certificats (<14 jours), augmentation des refus de poignée de main, baisse de la proportion de TLS 1. 3, erreurs de stapling OCSP.
Procédures : Remplacement d'urgence CA/racine, révocation de la clé compromise, désactivation de la 0-RTT.

13) Chèques-feuilles

• Le TLS 1 est désactivé. 0/1. 1 et les suites faibles sont inclus AEAD et PFS.
• L'ALPN est configuré (h2/h3) ; interdiction du h2c.
• HSTS est activé (pour les domaines publics), il n'y a pas de contenu mixte.
• Certificats auto-mis à jour, OCSP stapling fonctionne.
• Les canaux internes sont protégés par mTLS (ou l'équivalent de WireGuard/IPsec).
• Validation vérifiée des hôtes/chaînes dans les clients/SDK.

• Surveillance des versions TLS/ALPN/erreurs et expirations.
• Plan crypto-agility (traduction en nouveaux suites/courbes).
• Pentestes périodiques du canal et rhubarbe des confits.

14) FAQ

Q : Le TLS est-il suffisant uniquement sur le périmètre ?
Oh non. Le trafic interne doit également être crypté (mTLS/tunnels/mesh), en particulier dans les nuages et dans la multirendité.

Q : Ai-je besoin de 0-RTT ?
R : Activez le point pour les requêtes idempotentes, sinon désactivez-le en raison du risque de repli.

Q : Que choisir pour l'inter-centre de données ? IPsec ou WireGuard ?
R : WireGuard est plus facile et rapide, IPsec est mature et largement pris en charge. Les deux sont valides avec une configuration correcte.

Q : Comment protéger les webhooks « en route » ?
À propos : HTTPS avec profil moderne + vérification du certificat de l'expéditeur (si mTLS) + signature de charge utile et vérification du délai (voir « Garantie de livraison des webhooks », « Signature et vérification des requêtes »).

• Cryptage At Rest
• Authentification et autorisation
• Signature et vérification des demandes
• Authentification S2S
• Gestion des clés et rotation