TLS für die Serverkommunikation

Anmerkung:

Üblicherweise empfahl die GWDG die Nutzung der Datenverschlüsselung anstelle der 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 bei der GWDG aber nicht zum Einsatz.

Umgekehrt verhält es sich bei der Nutzung von 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 TSM-Servern.
  • Teilweise erhebliche Rechenlast für die Ver- bzw. Entschlüsselung der Daten.

Aufgrund der Umsetzung des Prinzips „Privacy-by-default“ in TSM/ISP, das in den Versionen ab 7.1.8 bzw. 8.1.2 die Nutzung von SSL/TLS zwingend vorschreibt, wird auch die GWDG sukzessive die Verschlüsselung zunächst anbieten und vermutlich ab 2019 obligatorisch einführen.

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. Die notwendigen Schritte zum Einsatz von TLS auf den Server beschreiben wir im Admin Corner.

Wie anhang der Tabelle mit den Zertifikatsdateien erkennbar, kommen permanent weitere Server hinzu, zunächst nur mit „self signed Certificates“, später auch mit offiziellen DFN-Zertfikaten.

Für die neuen Server (SM281, SM283, SM285) wird über eine Serveroption SSL zwingend voreingestellt, diese akzeptieren keine Verbindungen ohne Verschlüsselung!

Ablauf

Der Ablauf für Windows-, Linux- und MacOS-Clients ist nahezu gleich, daher wird er hier zunächst beschrieben.

  1. Zertifikatsdatei herunter laden und speichern (für die Beispiele gehen wir vom Speichern direkt im Ordner der Client-Konfiguration aus)
  2. Auf dem Client einen keyring erzeugen (nur Linux)
  3. Das Server-Zertifikat in diesen Keyring einfügen
  4. Konfiguration des Clients anpassen
  5. Verbindung prüfen

Beispiele

Da wir das Zusammenspiel ISP8-Client mit ISP8-Server noch nicht testen konnten, empfehle wir zunächst beim 7.1.6.5'er Client zu bleiben.

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