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	–