Empfehlung zum Einsatz von Transportverschlüsselung von Serverdiensten

Institute und Einrichtungen dürfen IT selbst betreiben und werden so zu Anbietern von Serverdiensten für Ihre Benutzer. Es wird empfohlen, dass derartige Dienste nach Möglichkeit verschlüsselt anzubieten sind. Ein Fokus sollte dabei auf den Webdiensten liegen, die nach Möglichkeit stets verschlüsselt angeboten werden sollten.

Auswahl einer geeigneten SSL/TLS Protokollversion

Umgangssprachlich wird bei Webservern häufig von einer Datenübertragung mittels SSL gesprochen. Dabei ist das aus den 1990iger Jahren stammende SSL-Protokoll (der Version 3.0) über direkte Weiterentwicklung durch das TLS-Protokoll (Transport Layer Security) abgelöst und wird – so der Server-Dienst für eine sichere Übertragung konfiguriert ist – bei einer breiten Palette von Server-Diensten verwendet. Auch TLS wurde in den vergangenen Jahren weiterentwickelt.

Die SSL Version 3.0 und älter sollen nicht mehr verwendet werden. Auch bei der Verwendung von TLS sollte die Versionen 1.0 und 1.1 möglichst gemieden und statt dessen nach Möglichkeit auf die Version 1.2 gesetzt werden. Insbesondere gilt dies bei der Neuimplementierung von Diensten.

Da verschiedene neuere Angriffe eine Anpassung der Konfiguration erfordern, stellt sich die Frage, wie IT-Administratoren die sich ändernden Anforderungen in die Wahl der geeigneten Parameter und Einstellmöglichkeiten für die Verwendung passender Verschlüsselungsalgorithmen umsetzten können. Dabei sind zuletzt mehrfach im Jahr aufgrund von Erkenntnissen über die Sicherheit von TLS-Konfigurationen Anpassung notwendig geworden. Es steht zu erwarten, dass dies auch in Zukunft der Fall sein wird.

Anpassung von Konfigurationen und Auswahl geeigneter kryptographischer Verfahren („Cypher-Suites“)

Insbesondere die Hersteller von Internetbrowsern aber auch Hersteller anderer Software reagieren bei neuen Erkenntnissen inzwischen in kürzeren Zeitabständen, so dass Benutzer auf Ihren Systemen immer neue Fehlermeldungen über als unsicher anzusehende Konfigurationen angezeigt bekommen. Dies zwingt zum einen die Anbieter eines Dienstes zum Reagieren und führt zum anderen zu einem erhöhten Supportaufwand für die Betreuung der betroffenen Benutzer.

Daher sollten IT-Administratoren die Konfiguration von TLS verwendenden Servern immer wieder anpassen, damit die Transportverschlüsselung sicher bleibt und moderne Client-Software ohne störende Warnmeldungen darauf zugreifen kann. Regelmäßig sind insbesondere

  • Webserver
  • Exchange/IMAP/POP3/SMTP Server
  • VPN-Server
  • LDAP-Server

zu überprüfen. Das Projekt https://bettercrypto.org hält eine derzeit fortlaufend aktualisierte Ausarbeitung unter dem Titel „Applied Crypto Hardening“ vor, die Konfigurationshinweise zu verschiedenen Anwendungen als Ausgangspunkt für eigene Anpassungen vorhält.

IT-Administratoren müssen abwägen, wie viele alte Clients noch im Umlauf sind mit denen auf die Dienste zugegriffen wird. Es besteht das Dilemma, dass alte Clients mit angepassten modernen Konfigurationen nicht mehr kompatibel aber gleichzeitig modernere Konfigurationen für eine sichere Transportverschlüsselung notwendig sind. Eine unreflektierte Übernahme von als besonders sicher anzusehenden Konfigurationsvorschlägen kann daher auch ernsthafte Betriebsstörungen hervorrufen.

Konfigurationsvalidierung und Verwendung von Testwerkzeugen

IT-Administratoren sollten daher allgemein anerkannte Testwerkzeuge verwenden, um daraus Hinweise zur gebotenen Konfiguration und deren Kompatibilität zu Clients und Betriebssystemen abzuleiten. Da die meisten eigenen Dienste weltweit über das Internet angeboten werden, bieten sich hier auch online-Tests verschiedener Anbieter an. Unter anderem wurden positive Erfahrungen berichtet zu den SSL-Tests von Qualys https://www.ssllabs.com/ssltest/. Der Fokus liegt dabei auf Web-Anwendungen. Ein „A-Rating“ ist anzustreben.

Die Mozilla-Foundation als einer der wichtigsten Browser-Hersteller bietet einen Generator für TLS-Konfigurationen unter dem URL https://mozilla.github.io/server-side-tls/ssl-config-generator/ an, die als Ausgangspunkt für eigene Konfigurationen dienen können. Ferner steht unter https://observatory.mozilla.org ein weiteres Testwerkzeug zur Verfügung, dass Hinweise und Empfehlungen für viele zusätzliche Aspekte liefert und unter anderem auch Hinweise von anderen Seiten wie beispielsweise https://securityheaders.io in seinen Ergebnissen mit integriert.

In diesem Zusammenhang muss aber auch erwähnt werden, dass die Kategorisierung in einem ABC-System immer nur alle in den genannten Tests verwendeten Merkmale auswertet, auch wenn dies gewichtet geschieht. Ob ein Merkmal im konkreten Einsatzszenario sinnvoll in einer bestimmten Art und Weise umgesetzt werden kann, steht dabei auf einem anderen Blatt.

Bei Microsoft erfolgt die Konfiguration über Registry-Keys. Die vorhandenen Registry-Keys sind unter dem URL https://technet.microsoft.com/en-us/library/dn786418.aspx referenziert. Einerseits ist die Konfiguration über Registry-Keys den Microsoft-Produkten innewohnend, andererseits stellt es an die IT-Administratoren besondere Anforderungen, den Überblick zu bewahren. Ferner liefert Microsoft einige Änderungen auch über automatische Updates aus, so dass tendenziell weniger Eingriffe nötig sind aber andererseits auch ohne Zutun des Administrators Änderungen seitens Microsoft Betriebsstörungen hervorrufen können. Im Fall Microsoft liefert der URL https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12 konkrete Konfigurationshinweise und ausführliche Erläuterungen.

Verwendung von HSTS fördern

Generell wird empfohlen auf eine vollständige Bereitstellung von TLS-gesicherten Inhalten hinzuwirken. Wenn möglich soll darauf verzichtet werden, Webseiten mit gemischten Inhalten anzubieten, da dies die Gefahr birgt dass bei Anpassungen im Bereich der Webseitenentwicklung unverschlüsselte Übertragungskanäle entstehen, die einem Angreifer wertvolle Hinweise wie z.B. den Zugriff auf Sitzungsschlüsseln (session keys) oder Zugriff auf Cookies bieten.

Der Einsatz des Protokolls HTTP Strict Transport Security (HSTS) wird in diesem Zusammenhang empfohlen, da HSTS es erschwert bei Angriffen oder serverseitigen Konfigurationsproblemen von einer gesicherten auf eine ungesicherte Seite umzuleiten.

Verwendung von Zertifikaten aus der DFN-PKI

Im Rahmen der Mitgliedschaft im DFN-Verein besteht die Möglichkeit, für die Absicherung von Servern Zertifikate aus der DFN-PKI zu benutzen. Es ist darauf zu achten, dass auf den Servern die richtige und vollständige Zertifikatskette in der Konfiguration mit aufgenommen wird.

Die Verwendung von Zertifikaten aus der DFN-PKI ist nicht nur deshalb ratsam weil sie im Rahmen der zentral bereitgestellten Dienste derzeit kostenfrei angeboten werden, sondern auch weil einerseits das Root-Zertifikat als vertrauenswürdig in den Certificate Authority (CA-)Listen von Clients und Browsern enthalten ist als auch die CA in Deutschland in deutschen Rechenzentren betrieben wird, was in Punkto Datenschutzanforderungen ein wichtiger Aspekt ist.

Der DFN betreibt sowohl Server für Certificate Revocation Lists (CRL) als auch Online Certificate Status Protocol (OCSP)-Responder, um es Clients zu ermöglichen, den Gültigkeits-Status von Zertifikaten abzufragen. Es bietet sich daher auch an, in diesem Zusammenhang die Verwendung von OCSP-Stapling zusammen mit dem Zertifikatsprofils „Webserver MustStaple“ zu eruieren.

it-sec/websec.txt · Zuletzt geändert: 2016/08/31 14:51 von pilawa
Gauß-IT-Zentrum