SSL-Terminierung und Balancer
Kurze Zusammenfassung
SSL/TLS-Terminierung entfernt die Krypto-Last von Anwendungen und öffnet den Weg für L7-Routing, WAF, Rate-Limit, mTLS, kanarische Releases. Die wichtigsten Entscheidungen sind: wo man TLS (edge/ingress/inside mesh) abschließt, wie man balanciert (L4 vs L7), welche Chiffrierprofile man verwendet, wie man Zertifikate ohne Downtime aktualisiert und wie man p95 Latenzen und Fehler im SLO hält.
Wo man TLS beendet
Am Rand (CDN/Anycast/WAF): minimale Latenz für den Benutzer, globaler Schutz, Cache/Bot-Steuerung. Weiter - re-encrypt zum Backend.
Auf ingress L7 (Nginx/Envoy/HAProxy/ALB): Feinrouting über URI/Header, mTLS, JWT-Validierung.
End-to-End-TLS (passthrough L4): Wenn ein End-to-End-mTLS vor einem Pod/Service benötigt wird (z.B. strenger Compliance-Bereich).
Service Mesh (Envoy/Istio/Linkerd): automatisiertes mTLS innerhalb eines Clusters, Richtlinien und Telemetrie.
Praxis: häufiger - edge terminate → re-encrypt vor ingress; für PII/Zahlungen - mTLS vor Service.
L4 vs L7 Auswuchten
L4 (TCP/UDP): minimale Latenz, einfache Health-Checks (Port/TCP), passthrough TLS. Geeignet für gRPC auf TLS bei L7-Mangel.
L7 (HTTP/HTTPS/HTTP3): Routing nach Host/Pfad/Header/Cookies, WAF, Rate-Limits, kanarische Releases, Sticky-Sessions, Retrays/Timeouts.
TLS: Versionen, Schlüssel, Chiffren
Versionen: TLS 1. 3 überall, TLS 1. 2 als Fallback. Deaktivieren Sie 1. 0/1. 1.
Schlüssel/Serts: ECDSA (P-256) - schneller als RSA; kann Dual-Stack (ECDSA + RSA) für die Antike sein.
ALPN: `h2` и `http/1. 1`; für HTTP/3: „h3“ (QUIC/UDP)
OCSP Stapling: einschließen; HSTS auf öffentlichen Domains.
Schlüsselpools: Speicherung im KMS/HSM; automatische Verlängerung (ACME/Vertrauensbaum).
0-RTT (TLS 1. 3): Punkt (GET/idempotent) einschließen, Replay-Risiko berücksichtigen.
Grundlegendes Verschlüsselungsprofil (TLS 1. 2): `ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305`
TLS-Leistung
Resumption: Session Tickets/IDs - reduzieren die Handshake-Kosten.
ECDSA + ChaCha20 hilft auf mobilen/ohne AES-NI.
OCSP Stapling + kurze Ketten reduzieren p95.
HTTP/2/3: Multiplexing, weniger Verbindungen → unter p95.
Offload: pin CPU-Kerne unter crypto, aktivieren reuseport, tune socket-Puffer.
Sicherheit
mTLS: Client-cert für Admins/Operator-APIs erforderlich; CRL/OCSP für den Widerruf.
SNI/ECH: SNI - Standard; ECH (Encr. ClientHello) verbirgt die Domain (wenn der Edge-Provider unterstützt).
Strict Transport Security (HSTS): Prod-Domains, mit Vorsicht am Start.
TLS zwischen Hop-Ins: Re-Encrypt vor dem Service, auch innerhalb von DC (Zero-Trust).
Rate-Limit/Graue Ochsen: Auf L7 schützen die Api vor Bots/Brute-Force.
Beobachtbarkeit und SLO
SLO (Beispiele)
p95 TLS-handshake ≤ 80-120 ms (global), p95 TTFB ≤ 200-300 ms.
TLS-Fehler (handshake/peer-verify) ≤ 0. 1%.
Der Anteil der Zusammenfassungen ≥ 70% für wiederholte Besuche.
Metriken
`handshake_time`, `tls_version`, `alpn`, `cert_expiry_days`, `ocsp_staple_status`.
L7: `p50/p95/p99`, `5xx`, `429`, `upstream_rq_time`, `retry_budget`.
Kapazität: aktive Anschlüsse, CPS (Anschlüsse pro Sekunde), RPS.
Typische Configs
Nginx (L7 terminate + HTTP/2 + OCSP stapling)
nginx server {
listen 443 ssl http2 reuseport;
server_name api.example.com;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:...:ECDHE-RSA-CHACHA20-POLY1305';
ssl_ecdh_curve X25519:P-256;
ssl_certificate /etc/ssl/cert.pem; # полная цепочка ssl_certificate_key /etc/ssl/key.pem;
ssl_stapling on; ssl_stapling_verify on;
ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
proxy_pass https://upstream_pool;
}
}
upstream upstream_pool {
zone backends 64k;
server 10.0.1.10:8443 max_fails=3 fail_timeout=10s;
server 10.0.1.11:8443 max_fails=3 fail_timeout=10s;
keepalive 256;
}HAProxy (L7 terminate + stickiness + mTLS zum Backend)
haproxy frontend fe_https bind:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1 mode http http-response set-header Strict-Transport-Security max-age=31536000 default_backend be_api
backend be_api mode http balance roundrobin cookie SRV insert indirect nocache option httpchk GET /healthz server s1 10.0.1.10:8443 check ssl verify required ca-file /etc/haproxy/ca.pem server s2 10.0.1.11:8443 check ssl verify required ca-file /etc/haproxy/ca.pemEnvoy (L7 terminate + mTLS vom Kunden + Kanarienvogel)
yaml static_resources:
listeners:
- name: https address: { socket_address: { address: 0.0.0.0, port_value: 443 } }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress route_config:
virtual_hosts:
- name: api domains: ["api.example.com"]
routes:
- match: { prefix: "/" }
route:
weighted_clusters:
clusters:
- name: api-stable weight: 95
- name: api-canary weight: 5 http_filters:
- name: envoy.filters.http.router transport_socket:
name: envoy.transport_sockets.tls typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext common_tls_context:
tls_certificates:
- certificate_chain: { filename: "/etc/tls/cert.pem" }
private_key: { filename: "/etc/tls/key.pem" }
validation_context: # mTLS (опционально)
trusted_ca: { filename: "/etc/tls/ca.pem" }
require_client_certificate: trueAWS ALB/NLB (Konzept)
ALB (L7 terminate): HTTPS listener 443 (TLS 1. 2/1. 3), target group HTTPs:8443, health-check `/healthz`, stickiness (cookie).
NLB (L4 passthrough): TLS-Hörer 443, TCP-Gesundheitschecks, Ende-zu-Ende-SNI zum Pod.
CloudFront/Cloudflare: TLS edge + WAF + Bot-Management; origin — HTTPS only.
Zertifikate ohne Downtime aktualisieren
ACME (Let's Encrypt/private CA) mit automatischer Aktualisierung und heißem Neustart (Nginx' reload', Envoy SDS).
Doppelte Zertifikate (ECDSA + RSA) bei Migrationen.
Kettensteuerung: Prüfung von dazwischenliegenden CAs; OCSP Stapeln nach der Rotation.
Alerts: 'cert _ expiry _ days <21' und 'ocsp _ status! = good'.
Gesundheitschecks und Routing
L4: TCP connect, TLS handshake.
L7: HTTP 200/JSON-Token-Version, gRPC-Gesundheit.
Richtlinien: failover, weighted, latency, consistent-hash (cookie/IP) für sticky.
Retrays/Timeouts: Balance zwischen Nachhaltigkeit und doppelten Anfragen (Idempotenz!).
Kubernetes-Muster
Ingress Controller (Nginx/Envoy/HAProxy): Terminierung auf Ingress, 'ExternalDNS' für DNS-Einträge, 'cert-manager' für ACME.
Gateway API: deklarative TLSRoute/HTTPRoute mit Kanarienvögeln.
Service Mesh: automatische mTLS- pod↔pod, Richtlinien auf der Ebene „PeerAuthentication “/„ DestinationRule“.
Sicherheits-Checkliste
- TLS 1. 3 enthalten ist; 1. 0/1. 1 ausgeschaltet.
- Moderne Chiffren; ECDSA-Serts, wo die Unterstützung es erlaubt.
- OCSP Stapeln, komplette Ketten, HSTS.
- mTLS für Admins/Interconnects; Revokation von Client-Serts.
- Rate-Limit/Bot-Filter am Rand; Schutz gegen slowloris/oversized headers.
- Re-encrypt zu Backends (Zero-Trust).
- Geheimnisse/Schlüssel in KMS/HSM; Rotation und Prüfung der Ausstellung.
Beobachtbarkeit und Alerts
Метрики: TLS handshakes/sec, failure rate, session resumption rate, OCSP, p95/99, open conns, CPS, RPS.
Protokolle: SNI/ALPN/TLS-Version, Cipher, Client-Zertifikat (für mTLS), Upstream-Codes, Latenz-Breakdown.
Alerts: Wachstum '5xx/525', Rückgang der Resumption, 'cert _ expiry _ days', 'ocsp _ failed', Überschreitung von p95, Spitzen von '429'.
Typische Fehler
Terminierung am Rand und plain HTTP nach innen ohne Schutz.
Übermäßig lange CA-Ketten → das Wachstum von p95 handshake.
Kein OCSP-Stapeln → Blockieren auf Clients/Browsern.
Sticky-Sitzung ohne Berücksichtigung failover → „kleben“ auf dem degradierten Knoten.
0-RTT ist für Änderungswünsche → das Risiko einer erneuten Einreichung aktiviert.
Das Fehlen von Hot-Reload-Serts → Sekundentropfen während der Rotation.
Spezifität für iGaming/Fintech
Peaks (Turniere/Matches): Erwärmung der TLS-Sessions (Pre-Connect), kurze Ketten, hoher Anteil an Resumption, HTTP/2/3 für die Fronten.
Payment Gateways/PSPs: mTLS, strikte Ciphers/Versionen, pinned CAs, separate Domains/ALBs mit strengen Regeln.
Anti-Fraud/Bot-Filter: L7-rate-limit über IP/ASN/device-fingerprint, kanarische Graue Ochsen (Challenge/Captcha) auf einer separaten Domain.
Regulatory: HSTS, auditierbare TLS-Parameterprotokolle, Versionsberichte, Rückruf von Client-Serts zu Vorfällen.
Mini-plejbuki
Kanarienfreigabe über L7-Balancer
1. Fügen Sie einen 'api-canary' Cluster mit einem Gewicht von 5% hinzu; 2) Achten Sie auf p95/Fehler; 3) 5→25→50→100%; 4) Selbstdrehen beim Abbau.
Notfallrotation des Zertifikats
1. Laden Sie die neue cert/key; 2) 'reload' ohne Drop-Anschlüsse (SDS/Hot-Swap); 3) OCSP-Prüfung; 4) dashboard p95 handshake.
Einbeziehung von HTTP/3
1. Öffnen Sie UDP/443; 2) ALPN 'h3' hinzufügen; 3) separate QUIC Verlust/RTT Metriken; 4) A/B nach Kundenanteil.
Ergebnis
Effektive SSL-Terminierung ist ein modernes TLS-Profil, der richtige Ort der Fertigstellung, intelligentes L7-Routing, Beobachtbarkeit und strenge Sicherheit (mTLS, HSTS, re-encrypt). Erfassen Sie alles in IaC, automatisieren Sie Rotationen, messen Sie p95/Fehler und verwenden Sie Kanarienvögel - so übersteht die Front Spitzen und ist vorhersehbar schnell und sicher.