In Transit-Verschlüsselung

In Transit-Verschlüsselung

1) Definition und Grenzen der Kontrolle

In-Transit-Verschlüsselung ist der Schutz von Daten auf dem gesamten Weg der Netzwerkübertragung (Browser ↔ Server, Service ↔ Service, Agent ↔ Broker, Basis ↔ Anwendung, Datacenter ↔ Datacenter), so dass passives Abfangen und aktive Angriffe auf den Kanal den Inhalt nicht offenbaren und es nicht erlauben, ihn ohne Erkennung zu ändern.

Was wir abdecken: öffentliche und private APIs (HTTP/HTTPS, gRPC), Streaming und Broker (Kafka, NATS, RabbitMQ), WebSocket, Basen und Caches über das Netzwerk, Dienstverkehr innerhalb von Clustern, VPN/zwischen Rechenzentren und Clouds, DNS-Abfragen, mobile/IoT-Clients.

Was wir nicht vollständig abdecken: Angriffe auf Endpunkte (Host/Browser-Kompromittierung), Anwendungsschwachstellen, Protokoll-/Dump-Leaks. Dies wird durch separate Kontrollen (A&A, Rechteminimierung, Verschlüsselung bei Rest, sichere Protokollierung) gelöst.

2) Bedrohungsmodell und Ziele

Risiken: Traffic Interception/Swap (MITM), Protokoll-Downgrade/Chiffrosuit, gefälschte Zertifikate/CA, Schlüssel-Leak, SNI/Metadaten-Angriffe, gemischte Inhalte, falsche TLS-Terminierung auf Balancern, unsichere Interservice-Verbindungen.

1. Vertraulichkeit + Integrität mit kryptografischer Authentifizierung.

2. Konfrontation mit dem Downgrade (strenge Politik und config).

3. Identifizierung der Parteien (Server, falls erforderlich - gegenseitig).

4. Verwalteter Lebenszyklus von Zertifikaten/Schlüsseln und Auditing.

5. Leistungsprofil ohne Sicherheitskompromisse.

3) Grundprinzipien

TLS ist überall Standard. Externer und interner Verkehr - wir verschlüsseln.
Moderne Versionen. TLS 1. 3 als Standard; TLS 1. 2 - nur unter strengen Richtlinien. 1. Deaktivieren. 0/1. 1.
AEAD-Verschlüsselungen mit PFS. AES-GCM oder ChaCha20-Poly1305; PFS über (EC) DHE.
Kurven/Kei-Exchanges. X25519 (vorzugsweise) oder secp256r1 (P-256). RSA-Schlüssel sind ≥2048, besser ECDSA (P-256).
mTLS ist dort, wo es wenig Vertrauen gibt. Interservice-Kanäle, Admin-APIs, Broker, Basen - durch gegenseitige Authentifizierung.
HSTS für das Web. Erzwingen Sie HTTPS + preload für öffentliche Domains.
„Verschlüsseln-und-wieder-verschlüsseln“ bewusst. TLS-Terminierung am Perimeter + Re-Verschlüsselung zu Backends oder Passthrough - Auswahl nach Bedrohungsmodell.
Crypto-agility. Möglichkeit, Kurven/Summen/Versionen mit Null-Ausfallzeiten zu ändern.

4) Protokollstack und Skripte

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

ALPN: h2 für HTTP/2, h3 für HTTP/3 Verbot h2c (ohne TLS).
HTTP/3/QUIC: reduziert Latenz, eingebettete 0-RTT und Migration von Verbindungen; 0-RTT selektiv erlaubt (Replexrisiko).
gRPC: über h2/h3; obligatorisch TLS, optional mTLS + per-RPC Autorisierung.
WebSocket: nur wss ://; in Proxy/Balancer - korrektes Upgrade und TLS-Pinning der Domain.

4. 2 Service-übergreifender Verkehr und Service-Meshi

Sidecar-Modell (Istio/Linkerd usw.). Automatische mTLS, Auflösungsrichtlinien, Zertifikatsrotation.
SPIFFE/SPIRE. Dezentrale Service-Identitäten (SPIFFE ID), SVID-Zertifikate, kurze TTLs.
Die TLS-Parameter werden zentralisiert. Minimieren Sie die Vielfalt der Config im Code der Dienste.

4. 3 Broker/Streaming/Warteschlangen

Kafka/NATS/RabbitMQ: TLS für kliyent↔broker und broker↔broker; nach Möglichkeit mTLS.
SASL über TLS: Wenn mTLS nicht möglich ist, erfolgt die Authentifizierung über Token/Logins, der Kanal wird jedoch verschlüsselt.
ACLs und Autorisierung von Themen. Verschlüsselung ≠ Zugangskontrolle.

4. 4 Datenbanken und Caches

PostgreSQL/MySQL/SQL Server: Aktivieren Sie TLS, CN/SAN-Validierung, Pin CA/Root.
Redis/Memcached: stunnel/TLS-Radieschen verwenden; Verbot von Plain-Traffic in der Produktion.

4. 5 Netz/Tunnel

Zwischen Rechenzentren/Clouds: IPsec (IKEv2) oder WireGuard (ein moderner Satz von Primitiven).
Admin-Zugriff: SSH mit modernen CEH/Chiffren; Verbot von Passwörtern, nur Schlüssel/SSO.

4. 6 DNS und unterstützende Protokolle

DNS über HTTPS (DoH )/DNS über TLS (DoT) für Clients und innerhalb eines Clusters, sofern möglich.
Deaktivieren Sie gemischte Inhalte. Nichts von http ://auf https ://Seiten.

5) Zertifikate, PKI und Schlüsselmanagement

PKI-Modell: für externe Domains - öffentliche CAs; für internen Datenverkehr eine eigene CA oder SPIRE-CA.
Automatisierung: ACME/Cert-Manager für Kubernetes, kurze TTL, Auto-Rotation.
OCSP stapling и CRL. Stapeln an den Fronten aktivieren; Die Ketten werden regelmäßig aktualisiert.
Pinning - mit Vorsicht. In mobilen/Desktop-Clients - Pin CA/SPKI mit Notrollmechanismus.
Schlüsselspeicherung: private Schlüssel in HSM/KMS/Secret-Speichern; ein Minimum an Expositionen; Verbot der Protokollierung.

6) Konfigurationen: praktische Profile

• Versionen: TLS 1. 3 (erforderlich), 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“ (+ Optionen AES256/CHACHA20 falls erforderlich).
• Kurven: X25519, secp256r1.
• Zertifikate: ECDSA-bevorzugt, RSA-fallback.
• Sichere Überschriften: „Strict-Transport-Security“, „X-Content-Type-Options“, „X-Frame-Options“ (je nach Fall), „Referrer-Policy“.
• Cookies: 'Secure', 'HttpOnly', 'SameSite' (Lax/Strict nach Design).

• Ein Client-Zertifikat ist erforderlich.
• Kurze TTL Client SVID (Stunden/Tage), automatische Rotation.
• Richtlinien: Wer kann sich mit wem verbinden (intent-based/Arbeit über Mesh-Autorisierung).

7) Leistung und Zuverlässigkeit

Hardwarebeschleunigung: AES-NI/ARMv8 Crypto, bevorzugt ChaCha20-Poly1305 auf CPUs ohne AES-NI.
Session resumption: TLS 1. 3 tickets; über die Lebensdauer nachdenken (Balance zwischen Leistung und Sicherheit).
0-RTT: nur für idempotente Anfragen; Schutz vor Replays (Server-basierte Anti-Replay-Mechanismen).
Balancer/Proxies: Wählen Sie klar termination vs passthrough; bei Termination - Re-Verschlüsselung zum Backend.
Observability: ALPN Handshake/Fehler/Verhandlungsmetriken, TLS Prozentsatz 1. 3, Zertifikatsablauf, OCSP-Status.

8) Prüfung und Verifizierung

Scan des TLS-Profils. Regelmäßige Überprüfungen der unterstützten Versionen/Suits/Kurven und HSTS/OCSP.
Negative Tests: Downgrade-Verbot, Ablehnung schwacher Suits, Ausfall von Verbindungen ohne SNI/ohne gültiges Kettenzertifikat.
Kanal-Pentest: MITM-Simulationen, Pinning-Check in mobilen Clients, 0-RTT-Replay-Versuche.
Chaos-Tests: Ablauf/Entzug des Zertifikats, OCSP/CA nicht verfügbar.

9) Häufige Fehler und wie man sie vermeidet

TLS aktiviert, jedoch ohne Host-Validierung. Überprüfen Sie immer CN/SAN, verbieten Sie' InsecureSkipVerify'.
Gemischte Inhalte. Blockieren Sie HTTP-Ressourcen auf https-Seiten, verwenden Sie CSP.
Schwache/veraltete Versionen und Hits. TLS 1 deaktivieren. 0/1. 1, CBC/RC4/3DES.
Keine Re-Verschlüsselung nach innen. Der Plain-Verkehr vom Balancer zur App ist ein Risiko.
Langlebige Zertifikate. Machen Sie kurze TTLs und Auto-Updates.
Falsche SNI/ALPN hinter dem Proxy. Korrekte SNI/ALPN-Übertragung bei TLS-Pass-Tru/Termination.

10) Mini-Rezepte (Fragmente von Konfigurationen)

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) Richtlinien und Compliance

Mindestanforderungen: TLS 1. 3 wo immer möglich; TLS 1. 2 - mit einer begrenzten Anzahl von Suiten.
Regulatory: PCI DSS/Finsector - Verbot von schwachen Versionen/Suits; obligatorische Rotation und Audit.
Zero Trust-Ansatz: Identitäten für jede Arbeitsbelastung, kontinuierliche Validierung und Service-Level-Richtlinien.

12) Betrieb und SLO

SLO: ≥99% erfolgreiche Handshakes, ≥95% Traffic auf TLS 1. 3, 0% gemischter Inhalt.
Alertas: Ablauf der Zertifikate (<14 Tage), Anstieg der Handshake-Ausfälle, Rückgang des TLS-Anteils 1. 3, OCSP Stapeln Fehler.
Verfahren: Notfallersatz von CA/Wurzel, Rückruf des kompromittierten Schlüssels, Deaktivieren der 0-RTT.

13) Checklisten

• TLS 1 deaktiviert. 0/1. 1 und schwache Suits, AEAD und PFS enthalten.
• ALPN konfiguriert (h2/h3); Verbot von h2c.
• HSTS ist aktiviert (für öffentliche Domains), Mixed Content fehlt.
• Zertifikate werden automatisch aktualisiert, OCSP Stapling funktioniert.
• Interne Kanäle sind durch mTLS (oder gleichwertig mit WireGuard/IPsec) geschützt.
• Validierte Host/Chain-Validierung in Clients/SDKs.

• Überwachung von TLS/ALPN/Fehler- und Ablaufversionen.
• Crypto-Agility Plan (Umstellung auf neue Eitelkeiten/Kurven).
• Periodische Kanal Pentests und Revue Config.

14) FAQ

F: Ist TLS nur am Perimeter ausreichend?
Oh, nein. Auch der interne Verkehr muss verschlüsselt werden (mTLS/Tunnel/Mesh), vor allem in den Clouds und bei Multiarrangements.

F: Brauche ich 0-RTT?
A: Schließen Sie Punkt für idempotent Anfragen ein, sonst - deaktivieren Sie wegen des Risikos des Repleys.

F: Was soll ich für das Inter-Rechenzentrum wählen? IPsec oder WireGuard?
A: WireGuard ist einfacher und schneller, IPsec ist ausgereift und weit verbreitet. Beides ist bei richtiger Konfiguration zulässig.

F: Wie kann man Webhooks „unterwegs“ schützen?
A: HTTPS mit modernem Profil + Überprüfung des Absenderzertifikats (wenn mTLS) + Payload-Signatur und Timestamp-Überprüfung (siehe „Webhook Delivery Guarantees“, „Signing and Request Verification“).

• „At Rest Verschlüsselung“
• „Authentifizierung und Autorisierung“
• „Signieren und Verifizieren von Anfragen“
• „S2S-Authentifizierung“
• „Schlüsselmanagement und Rotation“