Redis TLS-Verschlüsselung End-to-End konfigurieren: Server, Client, Rotation

1. Warum unverschlüsselte Redis-Verbindungen ein reales Risiko sind

Redis wurde ursprünglich für den Betrieb innerhalb eines vertrauenswürdigen internen Netzwerks entworfen, in dem Clients und Server derselben Sicherheitszone angehörten. Dieses Modell funktioniert in einer klassischen Serverfarm mit fester Netzwerktopologie gut, gerät aber in modernen Umgebungen schnell an seine Grenzen. Container-Orchestrierung, dynamische Cloud-Netzwerke und Multi-Tenant-Infrastruktur sorgen dafür, dass Datenverkehr zwischen Anwendung und Redis-Instanz häufiger über Netzwerksegmente hinweg läuft, die nicht mehr vollständig unter eigener Kontrolle stehen.

Ohne Transportverschlüsselung lässt sich der komplette Datenverkehr zwischen Anwendung und Redis mitschneiden, inklusive Session-Daten, Zugangsdaten für andere Systeme im Cache und potenziell sensible Geschäftsdaten aus dem Produktkatalog. Gerade in regulierten Branchen mit Anforderungen wie PCI DSS oder einer datenschutzkonformen Verarbeitung personenbezogener Daten reicht eine reine Firewall-Regel als Nachweis der Verschlüsselung in Bewegung nicht mehr aus, weshalb TLS zunehmend als Grundvoraussetzung statt als optionale Härtungsmaßnahme betrachtet wird.

2. Server-seitige TLS-Konfiguration in redis.conf

Seit Redis 6 bringt der Server native TLS-Unterstützung mit, die über eigene Konfigurationsdirektiven aktiviert wird, statt wie früher einen vorgeschalteten Proxy wie stunnel zu benötigen. Der klassische Klartext-Port lässt sich vollständig deaktivieren, sodass ausschließlich der verschlüsselte TLS-Port für eingehende Verbindungen zur Verfügung steht. Zertifikat, privater Schlüssel und die vertrauenswürdige Zertifizierungsstelle werden dabei als Dateipfade hinterlegt.

Die Direktive tls-auth-clients steuert, ob der Server von jedem Client ein gültiges Client-Zertifikat verlangt, also echtes mutual TLS erzwingt, oder ob eine einseitige Verschlüsselung ohne Client-Authentifizierung ausreicht. Für Produktionsumgebungen mit mehreren Anwendungsdiensten empfiehlt sich mutual TLS, weil dadurch nicht nur der Transportweg verschlüsselt, sondern auch die Identität jedes verbindenden Dienstes kryptografisch geprüft wird, was ein einfaches Passwort niemals leisten kann.

# redis.conf: TLS-Port aktivieren, Klartext-Port deaktivieren
port 0
tls-port 6379
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-auth-clients yes
tls-protocols "TLSv1.2 TLSv1.3"

3. Client-seitige TLS-Konfiguration und mutual TLS

Auf Client-Seite muss redis-cli für Diagnosezwecke ebenso wie jede Anwendungsbibliothek die TLS-Parameter kennen: das eigene Zertifikat und den privaten Schlüssel für mutual TLS sowie das CA-Zertifikat, um die Identität des Servers zu prüfen. Fehlt die Server-Verifikation, lässt sich zwar der Datenverkehr verschlüsseln, ein Man-in-the-Middle-Angriff mit einem gefälschten Server-Zertifikat bliebe jedoch unentdeckt, weshalb die CA-Prüfung niemals übersprungen werden sollte, auch nicht testweise in vermeintlich sicheren internen Netzen.

In einem Magento-Kontext läuft die eigentliche Verbindung meist über phpredis als PHP-Erweiterung, die TLS über einen Stream-Context-Array entgegennimmt. Die relevanten Optionen entsprechen inhaltlich denselben Parametern wie bei redis-cli, nur eben als PHP-Array statt als Kommandozeilenflag, und lassen sich zentral in der env.php des Magento-Deployments für Cache-, Session- und Full-Page-Cache-Backend gemeinsam pflegen.

# Verbindungstest mit redis-cli über TLS inklusive Client-Zertifikat
redis-cli --tls \
  --cert /etc/redis/tls/client.crt \
  --key /etc/redis/tls/client.key \
  --cacert /etc/redis/tls/ca.crt \
  -h redis.internal -p 6379 PING

4. Wie viel Performance kostet die TLS-Terminierung wirklich

Der spürbarste Kostenpunkt von TLS liegt nicht im laufenden Datenverkehr, sondern im initialen Handshake einer neuen Verbindung. Dieser Handshake basiert auf asymmetrischer Kryptografie, dem Aushandeln eines Sitzungsschlüssels und mehreren Netzwerk-Roundtrips, bevor die eigentliche Nutzlast überhaupt fließen kann. Bei kurzlebigen Verbindungen, die für jede Anfrage neu aufgebaut und sofort wieder geschlossen werden, kann dieser Handshake die tatsächliche Nutzdatenübertragung an Zeit deutlich übersteigen.

Ist die Verbindung erst einmal etabliert, fällt der laufende Verschlüsselungsaufwand kaum noch ins Gewicht. Moderne CPUs bringen mit AES-NI eine Hardwarebeschleunigung für die symmetrische Verschlüsselung mit, sodass der Durchsatz bei bereits bestehenden TLS-Verbindungen nur wenige Prozent unter dem einer unverschlüsselten Verbindung liegt. Der eigentliche Hebel für Performance liegt deshalb nicht im Verzicht auf TLS, sondern in der Vermeidung unnötig vieler neuer Handshakes.

5. Connection-Reuse als wichtigster Hebel gegen TLS-Overhead

In PHP-basierten Anwendungen wie Magento entsteht der größte TLS-Overhead häufig nicht durch Redis selbst, sondern durch das Ausführungsmodell: Jeder PHP-FPM-Prozess baut standardmäßig für jede Anfrage eine neue TCP- und TLS-Verbindung auf und schließt sie am Ende des Requests wieder. Bei hoher Anfragelast summiert sich dieser wiederholte Handshake zu einem messbaren Overhead, der bei unverschlüsselten Verbindungen so nicht sichtbar wäre.

phpredis unterstützt persistente Verbindungen über pconnect, wodurch die zugrundeliegende TCP- und TLS-Verbindung über mehrere Requests hinweg innerhalb desselben PHP-FPM-Worker-Prozesses wiederverwendet wird. Für die konkrete Konfiguration bedeutet das, den Cache- und Session-Backend-Einstellungen in Magentos env.php gezielt persistent_connection zu aktivieren, wodurch der teure Handshake nur noch beim ersten Request eines Worker-Prozesses stattfindet statt bei jedem einzelnen.

6. TLS Session-Resumption richtig konfigurieren

Auch bei nicht persistenten Verbindungen lässt sich der Handshake-Aufwand über TLS Session-Resumption reduzieren. Der Server merkt sich dabei Parameter einer bereits abgeschlossenen Sitzung in einem Session-Cache und erlaubt einem wiederkehrenden Client einen abgekürzten Handshake, der ohne den vollen asymmetrischen Schlüsselaustausch auskommt. Das reduziert sowohl die Netzwerk-Roundtrips als auch die CPU-Last für die erneute Verbindung spürbar.

In Redis wird dieses Verhalten über tls-session-caching sowie die zugehörige Cache-Größe und Timeout-Werte gesteuert. Eine zu klein dimensionierte Cache-Größe führt dazu, dass Session-Einträge unter Last vorzeitig verdrängt werden und der Vorteil praktisch verpufft, während ein zu langes Timeout ältere Sitzungsschlüssel unnötig lange vorhält und damit ein geringfügig größeres Zeitfenster für eine Kompromittierung offenlässt, weshalb beide Werte an das tatsächliche Verbindungsmuster angepasst werden sollten.

# redis.conf: Session-Resumption für abgekürzte Handshakes aktivieren
tls-session-caching yes
tls-session-cache-size 20000
tls-session-cache-timeout 300

7. Zertifikate im laufenden Betrieb rotieren ohne Downtime

Ein TLS-Zertifikat läuft irgendwann ab, und ein reiner Server-Neustart zum Austausch von Zertifikat und Schlüssel würde in einem produktiven Magento-Setup jede aktive Cache- und Session-Verbindung unterbrechen. Seit Redis 6.2 lassen sich tls-cert-file und tls-key-file jedoch zur Laufzeit über CONFIG SET austauschen, ohne den Prozess neu zu starten und ohne bestehende Verbindungen zu kappen.

Der bewährte Ablauf besteht darin, das neue Zertifikat samt Schlüssel bereits vor dem eigentlichen Ablaufdatum auf dem Server bereitzustellen, per CONFIG SET zu aktivieren und anschließend über einen erneuten TLS-Verbindungstest zu verifizieren, dass der Server tatsächlich das neue Zertifikat ausliefert. Erst danach wird das alte Zertifikat als ungültig markiert, sodass zu keinem Zeitpunkt eine Lücke zwischen abgelaufenem altem und noch nicht aktivem neuem Zertifikat entsteht.

# Zertifikat zur Laufzeit austauschen, ohne den Server neu zu starten
redis-cli -a "$ADMIN_PASS" CONFIG SET tls-cert-file /etc/redis/tls/redis-new.crt
redis-cli -a "$ADMIN_PASS" CONFIG SET tls-key-file /etc/redis/tls/redis-new.key
redis-cli -a "$ADMIN_PASS" CONFIG REWRITE

8. TLS-Handshakes überwachen und verifizieren

Nach jeder Änderung an Zertifikaten oder Cipher-Konfiguration lohnt sich eine direkte Verifikation über openssl, um festzustellen, welches Zertifikat, welches Ablaufdatum und welche ausgehandelte Cipher-Suite eine Verbindung tatsächlich verwendet. Dieser Test läuft unabhängig von der eigentlichen Anwendung und deckt Konfigurationsfehler auf, bevor sie im produktiven Betrieb zu Verbindungsabbrüchen führen.

Zusätzlich sollte das Ablaufdatum der Zertifikate als eigene Monitoring-Metrik erfasst werden, mit einem Alarm deutlich vor dem tatsächlichen Ablauf, da ein abgelaufenes Server-Zertifikat sämtliche neuen Verbindungen blockiert und bestehende, bereits etablierte Verbindungen zwar zunächst weiterlaufen, aber bei einem Neuaufbau ebenfalls scheitern. Ein Monitoring-Skript, das täglich das Restlaufzeit-Fenster prüft, verhindert zuverlässig, dass eine Zertifikatsrotation erst durch einen Produktionsausfall auffällt.

# Ausgehandelte TLS-Version, Cipher und Zertifikatsdaten prüfen
openssl s_client -connect redis.internal:6379 \
  -cert client.crt -key client.key -CAfile ca.crt \
  -tls1_3 2>/dev/null | openssl x509 -noout -dates

9. Checkliste für den produktiven TLS-Betrieb

Für einen belastbaren Produktivbetrieb gehören mehrere Maßnahmen zusammen: Der Klartext-Port bleibt vollständig deaktiviert, mutual TLS ist für jeden Dienst mit Schreibzugriff aktiv, und die erlaubten Cipher-Suiten werden über tls-ciphers sowie tls-ciphersuites explizit auf moderne, als sicher geltende Algorithmen eingeschränkt, statt sich auf die Standardauswahl der eingesetzten OpenSSL-Version zu verlassen.

TLS ersetzt dabei keine anderen Sicherheitsmechanismen, sondern ergänzt sie: Eine kombinierte Konfiguration aus TLS für die Transportverschlüsselung, ACL-Regeln für granulare Berechtigungen und einer klaren Netzwerksegmentierung ergibt in der Praxis die belastbarste Absicherung. Für Magento-Umgebungen bedeutet das konkret, dass Cache-, Session- und Full-Page-Cache-Verbindung dieselbe TLS-Konfiguration nutzen, damit keine unbemerkte Klartextverbindung als Rückfalloption übrig bleibt.

10. Zusammenfassung

11. FAQ: TLS in Redis: Das Wichtigste auf einen Blick