IT-Security: Sichere Cipher-Suites für TLS auswählen
Transportverschlüsselung mit TLS macht das Internet sicherer, muss aber regelmäßig an den Stand der Technik angepasst werden. Wir geben einen Überblick.
Thorsten Hübner
- Jan Mahn
TLS ist Pflicht, wenn man Dienste im Internet veröffentlicht – das zweifelt heutzutage kaum noch jemand an. Auch Websites ohne Log-in-Bereich und sensible Inhalte werden inzwischen anders als noch vor zehn Jahren über HTTPS ausgeliefert. Mit kostenlosen Zertifikaten von Let’s Encrypt und automatischer Verlängerung ist TLS heute mit wenigen Handgriffen ganz passabel eingerichtet. Doch wenn man mehr will als ganz passabel und tiefer in das Thema einsteigt, wird es kompliziert. In den Einstellungen von Webservern oder Reverse Proxies stößt man bei genauerem Hinsehen auf die Konfiguration der sogenannten Cipher-Suites und merkt: TLS ist nicht gleich TLS und die angebotenen Optionen sind nicht unbedingt selbsterklärend. Ist TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 die Einstellung der Wahl, oder sollte man lieber auf TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 setzen? Qualifiziert beantworten kann man die Frage erst nach einem Ausflug in die Kryptografie.
Die folgenden Hinweise gelten nicht nur für Webserver, auch Mailserver (mit IMAP und SMTP) oder Exoten wie MQTT-Server sollten nur mit sicheren TLS-Einstellungen betrieben werden. Hat man viele Dienste zu veröffentlichen, ist man gut beraten, einen Reverse Proxy vorzuschalten, der die TLS-Abwicklung zentral für HTTP und alle anderen Protokolle erledigt. In den Einstellungen der Server oder Reverse Proxys mit TLS-Funktion kann man immer mehrere Cipher-Suites gleichzeitig aktivieren. In einer perfekten Welt würde eine einzige Cipher-Suite ausreichen, am besten die mit den längsten Schlüsseln und den besten Verfahren. Dass man sich als Serverbetreiber überhaupt Gedanken über das Thema machen muss, hängt damit zusammen, dass nicht alle Clients (Mailprogramme, Browser, …) das neueste und beste Verfahren verstehen und auch die Server nicht immer die neueste und beste Technik beherrschen. Teils weil die Entwickler noch nicht die neuesten Krypto-Bibliotheken eingebunden haben, teils weil die Nutzer hoffnungslos veraltete Software einsetzen und Updates ohnehin für ein lästiges Übel halten.
Daher kann ein Server, der TLS beherrscht, immer mehrere Verfahren unterstützen und sich mit dem Client auf ein Verfahren einigen. Die Initiative geht vom Client aus, der dem Server mitteilt, welche Verfahren er kennt. Der Server entscheidet dann, welches der angebotenen Verfahren er nutzt. Das Problem: Wenn man neben sicheren auch unsichere Verfahren akzeptiert, um ganz alte Clients nicht auszuschließen, kann ein Angreifer, der als Man-in-the-Middle zwischen Client und Server sitzt, ein verwundbares Verfahren erzwingen. Dafür manipuliert er die Liste der unterstützten Verfahren, die der Client an den Server schickt (sogenannte Downgrade-Attacke). Die Abwägung besteht also darin, möglichst wenige (und nur sichere) Verfahren zuzulassen und gleichzeitig möglichst niemanden auszusperren.
Immer mehr Wissen. Das digitale Abo für IT und Technik.
Prepaid, Debit, Credit: Wie Sie die passende Kreditkarte finden
Statt Passwörter: Wie Sie Accounts mit Passkeys schützen
High-End-Smartphones im Kameravergleich: Wettkampf um die beste Bildqualität
Eigene Domain für zu Hause: Reverse-Proxy auf dem Raspberry Pi einrichten
Wie eine lokale KI die Fotosammlung auf dem NAS verschlagworten kann
Karrierewechsel: Warum sich ein Informatikstudium auch für Quereinsteiger lohnt
Immer mehr Wissen. Das digitale Abo für IT und Technik.
Prepaid, Debit, Credit: Wie Sie die passende Kreditkarte finden
Statt Passwörter: Wie Sie Accounts mit Passkeys schützen
High-End-Smartphones im Kameravergleich: Wettkampf um die beste Bildqualität
Eigene Domain für zu Hause: Reverse-Proxy auf dem Raspberry Pi einrichten
Wie eine lokale KI die Fotosammlung auf dem NAS verschlagworten kann