SSL/TLS-Best-Practices: Verschlüsselung bei der Übertragung

SSL/TLS-Best-Practices

Eine sichere SSL/TLS-Implementierung ist grundlegend, um Daten während der Übertragung vor Abfangen, Veränderung und Man-in-the-Middle-Angriffen zu schützen, die die Vertraulichkeit und Integrität sensibler Kommunikation gefährden können. Obwohl SSL/TLS weit verbreitet ist (praktisch jede moderne Website nutzt HTTPS), enthalten viele Implementierungen noch Schwachstellen, die auf unzureichende Konfigurationen zurückgehen: die Verwendung veralteter Protokollversionen (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1), die von Gremien wie der IETF und PCI-DSS aufgrund bekannter Schwachstellen wie POODLE, BEAST und CRIME offiziell deprecated wurden, schwache oder gebrochene Cipher Suites wie RC4, DES, 3DES und MD5, die sich mit modernen Rechenressourcen angreifen lassen, Zertifikate mit SHA-1-Signaturalgorithmen, die mittlerweile als unsicher gelten, fehlende Perfect Forward Secrecy (PFS), die es erlaubt, abgefangenen Datenverkehr rückwirkend zu entschlüsseln, falls der private Schlüssel des Servers künftig kompromittiert wird, das Fehlen von HSTS (HTTP Strict Transport Security), das Downgrade-Angriffe ermöglicht, bei denen ein Angreifer eine unverschlüsselte HTTP-Verbindung erzwingt, sowie unzureichendes oder fehlendes Certificate Pinning in kritischen Mobile-Anwendungen, das ein Abfangen über bösartige, auf dem Gerät installierte Zertifikate ermöglicht. Eine optimierte SSL/TLS-Konfiguration verbessert nicht nur die Security-Posture, sondern wirkt sich auch auf die Performance aus (TLS-1.3-Handshakes sind schneller als TLS 1.2), auf die Kompatibilität (sehr alte Clients unterstützen moderne Konfigurationen möglicherweise nicht) und auf die Compliance (LGPD, GDPR, PCI-DSS verlangen starke Verschlüsselung für Daten bei der Übertragung). Dieser Artikel liefert detaillierte technische Richtlinien zur Implementierung von SSL/TLS nach den Best Practices der Branche, den Empfehlungen des NIST, dem Mozilla SSL Configuration Generator und OWASP.

Protokollversionen: TLS 1.2 und TLS 1.3

Deaktivieren Sie SSL 2.0, SSL 3.0, TLS 1.0 und TLS 1.1 auf allen Servern vollständig - diese Versionen weisen dokumentierte Schwachstellen auf und sollten nicht einmal aus Kompatibilitätsgründen mit Legacy-Clients verwendet werden. Konfigurieren Sie Ihren Webserver (nginx, Apache, IIS) oder Load Balancer (AWS ALB, Azure Application Gateway) so, dass nur TLS 1.2 und TLS 1.3 akzeptiert werden. TLS 1.3, 2018 als RFC 8446 ratifiziert, bietet erhebliche Verbesserungen gegenüber früheren Versionen: einen schnelleren Handshake (1-RTT statt 2-RTT, mit 0-RTT-Unterstützung für Resumed Sessions), die Entfernung unsicherer Cipher Suites (es unterstützt kein RSA Key Exchange, keine Cipher im CBC-Modus, kein RC4, kein 3DES mehr), obligatorische Forward Secrecy in allen Cipher Suites und einen verschlüsselten Handshake, der die Metadaten der Protokollaushandlung verbirgt. Konfigurieren Sie in nginx mit "ssl_protocols TLSv1.2 TLSv1.3;". In Apache "SSLProtocol -all +TLSv1.2 +TLSv1.3". AWS ALB erlaubt die Auswahl einer Security Policy, die Protokolle und Cipher definiert - wählen Sie "ELBSecurityPolicy-TLS13-1-2-2021-06" für moderne Umgebungen oder "ELBSecurityPolicy-2016-08", wenn Sie einige ältere Clients unterstützen müssen. Überwachen Sie Ihre Zugriffslogs, um zu ermitteln, wie viele Clients noch TLS 1.0/1.1 verwenden - ist die Zahl unbedeutend (weniger als 0,1 % des Datenverkehrs), können Sie sie ohne nennenswerte Auswirkungen deaktivieren. Für B2B-APIs, bei denen Sie beide Endpunkte kontrollieren, fordern Sie ausschließlich TLS 1.3. Denken Sie daran, dass die Protokollversion während des Handshakes ausgehandelt wird - der Server muss die unterstützten Versionen ankündigen, und der Client wählt die höchste aus, die auch er unterstützt.

Cipher Suites: ECDHE und AES-GCM

Cipher Suites definieren die Algorithmen, die während einer TLS-Verbindung für Key Exchange, Authentifizierung, symmetrische Verschlüsselung und HMAC verwendet werden - eine unzureichende Wahl kann die gesamte Sicherheit der Kommunikation gefährden, selbst bei Verwendung von TLS 1.2+. Priorisieren Sie Cipher Suites mit ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) für den Key Exchange, da es Perfect Forward Secrecy bietet, sowie AES-GCM (Galois/Counter Mode) oder ChaCha20-Poly1305 für die symmetrische Verschlüsselung, da es sich um AEAD-Cipher (Authenticated Encryption with Associated Data) handelt, die sowohl Vertraulichkeit als auch Integrität gewährleisten. Beispiel für eine sichere Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 oder TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256. Vermeiden Sie vollständig: Cipher Suites mit RC4 (anfällig für statistische Verzerrungen), Export-Cipher (durch alte Exportbestimmungen auf 40 oder 56 Bit beschränkt), NULL-Cipher (ohne Verschlüsselung), DES und 3DES (kleine Blockgröße, anfällig für Sweet32), CBC-Modus in TLS 1.0-1.1 (anfällig für BEAST und Lucky13) sowie RSA Key Exchange ohne DHE/ECDHE (ohne Forward Secrecy). Konfigurieren Sie in nginx "ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';" und "ssl_prefer_server_ciphers on;", um die Reihenfolge des Servers zu erzwingen. Verwenden Sie Tools wie ssllabs.com/ssltest, um Ihre Konfiguration zu validieren und ein A+-Rating zu erhalten. Bei TLS 1.3 sind die Cipher Suites standardmäßig vereinfacht und sicherer (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256).

HSTS: HTTP Strict Transport Security

HSTS ist ein Mechanismus, der Browser anweist, für eine bestimmte Domain stets HTTPS zu verwenden, und so SSL-Stripping-Angriffe verhindert, bei denen ein Man-in-the-Middle eine unverschlüsselte HTTP-Verbindung erzwingt, indem er die erste Anfrage abfängt, bevor der 301-Redirect zu HTTPS erfolgt. Implementieren Sie HSTS, indem Sie den Header "Strict-Transport-Security" zu allen HTTPS-Antworten Ihres Servers hinzufügen: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload". Der Parameter max-age (in Sekunden) legt fest, wie lange sich der Browser merken soll, nur HTTPS zu verwenden - 31536000 Sekunden = 1 Jahr ist der empfohlene Wert. "includeSubDomains" wendet die Richtlinie auf alle Subdomains an (mit Vorsicht verwenden, da Sie sicherstellen müssen, dass ALLE Subdomains HTTPS unterstützen). "preload" gibt an, dass Sie Ihre Domain in die von Browsern gepflegte HSTS Preload List aufnehmen möchten - eine fest einprogrammierte Liste von Domains, die selbst beim ersten Besuch, bevor irgendein HSTS-Header empfangen wird, stets HTTPS verwenden müssen. Um in die Preload List aufgenommen zu werden, reichen Sie Ihre Domain auf hstspreload.org ein, nachdem Sie bestätigt haben, dass: die gesamte Website einwandfrei über HTTPS funktioniert, Sie über ein gültiges Zertifikat verfügen, das Domain und Subdomains abdeckt, Sie den gesamten HTTP-Verkehr auf HTTPS umleiten, Sie den HSTS-Header auf der Basisdomain mit den Direktiven includeSubDomains und preload ausliefern und max-age größer oder gleich 31536000 ist. WICHTIG: preload ist eine Einbahnstraßen-Entscheidung - das Entfernen einer Domain aus der Liste kann Monate dauern und wird den Zugriff für Benutzer in diesem Zeitraum unterbrechen, falls Sie HTTPS nicht mehr unterstützen können. In nginx: "add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload' always;". In Apache: "Header always set Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload'".

Certificate Pinning für kritische Anwendungen

Certificate Pinning ist eine Technik, bei der Ihre Anwendung (insbesondere Mobile-Apps und kritische APIs) den Hash/Fingerprint des erwarteten Serverzertifikats fest einprogrammiert oder einbettet und während des TLS-Handshakes überprüft, dass das vorgelegte Zertifikat mit dem gespeicherten Pin übereinstimmt - dies verhindert Angriffe, bei denen ein Angreifer ein bösartiges Zertifikat auf dem Gerät des Opfers installiert (über Malware oder physischen Zugriff) und HTTPS-Verkehr abfängt, der normalerweise durch die Standard-CA-Kette des Betriebssystems als vertrauenswürdig eingestuft würde. Es gibt zwei Arten von Pinning: das Pinnen des Leaf-Zertifikats (spezifisch für dieses Zertifikat, muss aktualisiert werden, wenn das Zertifikat abläuft/erneuert wird) oder das Pinnen des öffentlichen Schlüssels der CA / des öffentlichen Schlüssels (flexibler, ermöglicht die Rotation von Zertifikaten, solange sie von derselben CA signiert sind). Implementieren Sie Pinning in Mobile-Apps mit nativen Frameworks: das iOS Network Framework ermöglicht Pinning über URLSessionDelegate-Callbacks, Android verwendet die Network Security Configuration XML mit dem Element pin-set, React Native kann die Bibliothek react-native-ssl-pinning verwenden. Erwägen Sie für APIs mutual TLS (mTLS), bei dem auch der Client dem Server ein Zertifikat vorlegt, das per Pinning validiert wird. VORSICHT: Falsches Pinning kann Ihre Anwendung lahmlegen, wenn Sie den Zugriff auf das gepinnte Zertifikat verlieren und keinen Fallback-Mechanismus haben - implementieren Sie stets: einen Backup-Pin (ein zweites gültiges Zertifikat/eine zweite gültige CA), Over-the-Air-Pin-Updates und eine Grace-Periode, bevor Pins erzwungen werden, um in Notfällen ein Rollback zu ermöglichen. Verwenden Sie nach Möglichkeit Public Key Pinning anstelle von Certificate Pinning (widerstandsfähiger gegenüber Erneuerungen). Beispiel für eine Konfiguration unter Android mit einem SHA-256-Digest und einem Base64-Hash des öffentlichen Schlüssels. Tools wie openssl können den Hash des öffentlichen Schlüssels aus Zertifikaten extrahieren, um ihn in den Pins zu verwenden.

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy ist eine kryptografische Eigenschaft, bei der die Kompromittierung des langlebigen privaten Schlüssels des Servers (des privaten Schlüssels des SSL-Zertifikats) nicht die Entschlüsselung früherer, aufgezeichneter Sitzungen ermöglicht - dies wird durch die Verwendung dynamisch generierter ephemerer Schlüssel für jede Sitzung erreicht, die nach Gebrauch zerstört werden. Ohne PFS kann ein Angreifer, der den gesamten verschlüsselten Datenverkehr aufzeichnet (mit Network Taps trivial) und Jahre später Ihren privaten Schlüssel stehlen kann (über eine Datenpanne, eine Insider-Bedrohung, eine gerichtliche Anordnung), auf die gespeicherten pcaps zurückgreifen und ALLE historischen Sitzungen entschlüsseln - ein Szenario, das als "retrospective decryption" bekannt ist. PFS verhindert dies, indem es eindeutige Session Keys über Diffie-Hellman-Algorithmen generiert, die für die Ableitung nicht vom privaten Schlüssel des Zertifikats abhängen - selbst wenn der private Schlüssel kompromittiert wird, bleiben frühere Session Keys sicher, da sie mit ephemeren Komponenten generiert wurden, die nicht mehr existieren. Um PFS sicherzustellen, verwenden Sie nur Cipher Suites mit DHE (Diffie-Hellman Ephemeral) oder ECDHE (Elliptic Curve DHE) beim Key Exchange - vermeiden Sie RSA Key Exchange, das keine PFS bietet, da der Session Key mit dem öffentlichen Schlüssel des Servers verschlüsselt und mit dem privaten Schlüssel entschlüsselt wird. In TLS 1.3 ist PFS obligatorisch (alle Cipher Suites verwenden ECDHE). Konfigurieren Sie in TLS 1.2 den Server so, dass er ECDHE-Cipher gegenüber RSA bevorzugt. Validieren Sie mit: openssl s_client -connect ihreseite.com:443 -cipher 'ECDHE' - wenn die Verbindung erfolgreich ist, funktioniert PFS. Ein zusätzlicher Vorteil von PFS ist die Compliance - viele Frameworks (PCI-DSS, NIST) empfehlen oder verlangen PFS zum Schutz sensibler Daten. Nachteil: ein leichter Performance-Overhead, da DHE-Operationen rechnerisch teurer sind als RSA, doch mit moderner Hardware (AES-NI, CPU-Krypto-Beschleunigung) ist der Effekt vernachlässigbar.