Inhaltsverzeichnis
TLS für die Serverkommunikation
Anmerkung:
Üblicherweise empfahl die GWDG die Nutzung der Datenverschlüsselung anstelle der SSL/TLS-Transportverschlüsselung, da dies ein paar Vorteile bietet:
- Die Daten sind auf dem gesamten Weg vom Client bis zum Band verschlüsselt
- seitens der GWDG besteht keine Möglichkeit, Einblick in die Daten nehmen zu können.
- Es gibt keine zusätzliche Rechenlast auf dem TSM-Server.
Allerdings gibt es auch ein paar Nachteile:
- Der Schlüssel liegt beim Nutzer, geht dieser verloren, kann seitens der GWDG keine Hilfestellung gegeben werden.
- Es sind lediglich die Daten verschlüsselt, die Client-Server-Kommunikation ist prinzipiell abhörbar, z.B. über Arp-Angriffe im Subnetz des Clienten oder des Servers.
- Die Kompression der verschlüsselten Daten durch die Bandlaufwerke ist um ca. 10% weniger effektiv, es werden etwas mehr Bänder benötigt.
- DeDuplikation ist für verschlüsselte Daten kaum effektiv nutzbar – diese Technik kommt aber bei der GWDG (bisher) nicht zum Einsatz.
Umgekehrt verhält es sich bei der Nutzung von SSL/TLS als Transportverschlüsselung.
Vorteile:
- Unverschlüsselte Daten können auch seitens der GWDG auf expliziten Auftrag des Nutzers restored werden.
- Kompression und DeDuplikation arbeiten besser.
- Auch die Kommunikation neben dem Datenstrom ist verschlüsselt.
Nachteile:
- Die Daten liegen unverschlüsselt und damit nur durch die üblichen IT-Sicherheitsmaßnahmen der GWDG geschützt auf den SP-Servern.
- Teilweise erhebliche Rechenlast für die Ver- bzw. Entschlüsselung der Daten.
Mit den SP-Versionen 8 und neuer hat sich die IBM für einen weiteren Ansatz entschieden:
- die Kontroll-Sessions (z.B. Knotennamen + Password, Dateilisten) werden TLS-verschlüsselt (siehe auch die WICHTIG-Box)
- die Übertragung der eigentlichen Backupdaten erfolgt weiterhin unverschlüsselt.
Letztendlich werden damit die Vorteile aus Transport- und Client-Verschlüsselung kombiniert:
- die eigentlichen Daten werden bereits auf dem Client verschlüsselt und liegen bei der GWDG *immer* verschlüselt vor
- die Kommunikation zwischen Client und Server werden TSL-transportverschlüsselt.
Mit der Umsetzung des Prinzips „Privacy-by-default“ in TSM/SP, hat IBM in den Versionen ab 7.1.8 bzw. 8.1.2 die Nutzung von SSL/TLS zwingend eingeführt. Vermutlich aufgrund der damit einhergehenden Aufwände und Probleme gibt seit Version 8.1.5 TOFU, also Trust_On_First_Use, d.h. SP-Clients in den Versionen 8.1.5 und neuer akzeptieren bei der ersten Verbindung die Serverzertifikate und installieren sie selbstständig – ohne Eingriff des Nutzers.
Die GWDG wird daher alle SP-Server direkt von Version 7.1.7 auf 8.1.9 (oder neuer) umstellen, so dass alle Clients neuer 8.1.5 dank TOFU TLS nutzen können
Nutzung von TLS
Entsprechend der geänderten Empfehlung stellen wir SSL/TLS sukzessive für die Nutzung zur Verfügung. Zunächst nutzte es nur der Server TSM130 (dieser steht außerhalb der GÖNET-Firewall) und beschreiben daher hier die Nutzung. Dank TOFU wird mit dem Upgrade der Server auf SP8 die explizite Konfiguration von TLS entfallen. Die notwendigen Schritte zum Einsatz von TLS auf den Server beschreiben wir trotzdem im Admin Corner.
Wie anhang der Tabelle mit den Zertifikatsdateien erkennbar, kommen permanent weitere Server hinzu, zunächst nur mit „self signed Certificates“, die Nutzung offizieller DFN-Zertfikate ist noch in der Diskussion.
Ablauf
Der Ablauf für Windows-, Linux- und MacOS-Clients ist nahezu gleich, daher wird er hier zunächst beschrieben.
- Zertifikatsdatei herunter laden und speichern (für die Beispiele gehen wir vom Speichern direkt im Ordner der Client-Konfiguration aus)
- Auf dem Client einen keyring erzeugen (nur Linux)
- Das Server-Zertifikat in diesen Keyring einfügen
- Konfiguration des Clients anpassen
- Verbindung prüfen
Beispiele
Die ersten Erfahrungen mit SP8-Clients und SP8-Servern sind erfreulich und machen die TLS-Nutzung vollkommen unkompliziert. Wir empfehlen daher, entweder zunächst auf Version 7.1.6.5 zu bleiben oder direkt einen aktuellen SP8-Client zu installieren.
Serverzertifikate
self signed certificate
Im Rahmen des Testbetriebs werden zunächst self signed certificates benutzt.
Im ZIP-Archiv liegen alle aktuellen self-signed certificates:
Server | Zertifikat / Pfad | Prüfalgorithmus | Prüfsumme |
---|---|---|---|
SM130 | sm130/cert256.arm | sha256 | 19f42c0f581c3b3c401f93c8e5dca577a47ba12c4902332be08523c67195c9c7 |
SM131*) | sm131/cert256.arm | sha256 | 6bc1a4aac0dcb1740605fb3b6458b6335d35d6cbf513429b48d47b83d2edecd1 |
SM230*) | sm230/cert256.arm | sha256 | e8fa348a78b96b8a3dbc2548279922b58af8220ccc38f585b159cdcf69ece754 |
SM231 | sm231/cert256.arm | sha256 | b3908d34cebea5bb65c6b395fc09f0a0b8b5bb38d440d839fc0f727b89b3f3c8 |
SM232*) | sm232/cert256.arm | sha256 | f768f384a674fdb2760a7573649d1120afcbd49b8ae879e5cc74f4f573930a5b |
SM233*) | sm233/cert256.arm | sha256 | f0a8b03667598b72978f0244f662ea197de8e285126c0d0cba67bac299de85fc |
SM234 | sm234/cert256.arm | sha256 | b106d4786f348c5a098cb25398a6ef09e10b5de604dc2bcaef08e3b5db49302a |
SM235 | sm235/cert256.arm | sha256 | 7b4c0712ee654d5ef7948b14c0bab73ea0bd7ad24eeb49737aeb92e450dc213b |
SM236 | sm236/cert256.arm | sha256 | 5bb6c3816b0dae064c4372b129b2f2a5794a358d2327a825585797849d3d8b71 |
SM281 | sm281/cert256.arm | sha256 | e14ae9fa6956c5da62aa6783ec031da21c25f7ed4f8351a67c59db4f8656e454 |
SM283 | sm283/cert256.arm | sha256 | 09b8cceb979dc1a26c93606f68c5c34b9e05a289d818b29590bdff6714cdca0b |
SM285 | sm283/cert256.arm | sha256 | 04ee673136378cf261ce00c6b15f5ed0d2b31268bc10f504b0c7a6461cefbe7a |
*) ⇒ Neustart des Servers steht ggf. noch aus!
DFN certificate
Darüber hinaus sind folgende Zertifikate der DFN-PKI verfügbar
Server | Zertifikat | Prüfalgorithmus | Prüfsumme |
---|---|---|---|
– | noch keine | sha256 | – |