Nicht abschließend – TLS-Sicherheit in der Praxis - Prof. Dr. Norbert Pohlmann

J. Meng, N. Pohlmann:
„Nicht abschließend – TLS-Sicherheit in der Praxis“,
iX – Magazin für professionelle Informationstechnik, Heise-Verlag,
07/2019

TLS-Sicherheit
Das Institut für Internet-Sicherheit – if(is) hat zahlreiche Webseiten untersucht und ein aktuelles Bild der Sicherheitslage bei der verschlüsselten Datenübertragung im Internet erstellt. Das vom if(is) entwickelte Testwerkzeug steht für eigene tests öffentlich zur Verfügung.

Die im Mai 2018 in Kraft getretene Datenschutz-Grundverordnung (DSGVO) verpflichtet alle in der EU tätigen Unternehmen, den „Datenschutz durch Technikgestaltung“ zu gewährleisten. Dazu zählt insbesondere, personenbezogene Daten beim Übertragen durchs Internet mittels TLS (Transport Layer Security) zu schützen. Das zwar veraltete, aber zum Teil immer noch eingesetzte Vorgängerprotokoll SSL (Secure Sockets Layer) ist im Folgenden einbezogen. Die Verschlüsselung der zu übertragenden Daten mittels TLS dient dreierlei Zielen: Sie verhindert erstens den Zugriff durch Dritte während des Transports. Zweitens findet die Kommunikation inte-gritätsgesichert statt; niemand kann den Datenverkehr unbemerkt manipulieren. Die dritte Funktion ist die Authentifizierung der Kommunikationspartner. TLS-Sicherheit gewinnt also aus gutem Grund rasch an Beliebtheit: Von 2016 bis 2019 hat sich der Anteil der damit im Web geschützten Verbindungen auf über 75 % ungefähr verdreifacht.
TLS kommt also bei Milliarden von Verbindungen täglich zum Einsatz. Das im Folgenden beschriebene Testverfahren bestätigt jedoch den Eindruck, dass die Sicherheit häufig zu wünschen übrig lässt – lauern doch einige Fallen beim Konfigurieren: Überholte Protokollversionen lassen einige Angriffsmöglichkeiten zu, der Einsatz veralteter Verschlüsselungsmethoden (Cipher Suites) gefährdet die Datensicherheit und falsch konfigurierte Parameter lassen Einfallstore für Angreifer offen.

Sichere Protokollversionen und Einstellungen
Die Verbindungsparameter stellt der Server in der ersten von zwei Phasen ein: beim Aufbau der Verbindung. Er berücksichtigt dabei die vom Client angegebenen Konfigurationsmöglichkeiten. Diese „Handshake-Phase“ entscheidet über die Sicherheit der Verbindung. In der Regel leitet der Client die Handshake-Phase ein und sendet die Nachricht „ClientHello“. Diese enthält eine Liste der Cipher Suites, die der Client – meist ein Webbrowser – beherrscht. Der Server entscheidet, welche davon zum Einsatz kommt, im Idealfall die sicherste Variante. Er kann die Verbindung ablehnen, wenn er keine vom Client vorgeschlagene Cipher Suite akzeptiert.
Das hier vorgestellte Testwerkzeug simuliert einen Client, der viele unterschiedliche Verbindungen nacheinander aufbaut. Es verwendet dabei jeweils unterschiedliche Parameter (TLS-Version, Cipher Suites) in einer „ClientHello“- Nachricht. So gibt es zum Beispiel vor, dass der Client nur die veraltete SSL-Version 2.0 beherrscht, um herauszufinden, ob der Server dieses Protokoll akzeptiert.

Der Server antwortet dem Testtool per „ServerHello“-Nachricht, ob er die Verbindung annimmt. Für die Sicherheit ist es entscheidend, dass der Server keine alten und unsicheren Protokollversionen und Cipher Suites akzeptiert. Wenn er eine Verbindung mit SSL 2.0 aufzubauen bereit ist, offenbart dies gravierende Mängel. Der Test beantwortet also die Frage: Welches sind die unsichersten Parameter, die der Webserver akzeptiert?
Beim Laden einer Webseite über eine TLS-gesicherte Verbindung initiiert der Webbrowser den Verbindungsaufbau. Anwender richten nur in Ausnahmefällen ihr Augenmerk auf die TLS-Konfiguration – zum Beispiel, wenn ein Zertifikat des Servers abgelaufen ist und der Browser einen entsprechenden Warnhinweis gibt. Die meisten Nutzer befassen sich nicht mit den Details, sondern belassen es bei den Voreinstellungen des Browsers. Diese Standardkonfigurationen lassen oft veraltete Protokolle wie TLS 1.0 zu, was im Hinblick auf die Sicherheit unverantwortlich ist. Umso mehr Verantwortung liegt bei den Website-Betreibern, beim Konfigurieren des Servers auf sichere TLS-Einstellungen zu achten.
Das Testtool bewertet die TLS-Konfigurationen anhand von Zertifikat und
Schlüssel, Protokollversionen, HTTP- Header sowie weiterer Kriterien. Zunächst prüft es, ob die in die Adresszeile des Browsers eingegebene Domain mit derjenigen im Zertifikat übereinstimmt.
Jede Instanz, die eine TLS-Verbindung aufbaut, enthält einen Zertifikatsspeicher (Trust Store) mit sogenannten Wurzelzertifikaten (Root Certificates). Bei diesen Instanzen handelt es sich beispielsweise um Webbrowser wie Firefox. Die müssen eine Vertrauenskette (Chain of Trust) vom Wurzelzertifikat bis zum Zertifikat des besuchten Webservers aufbauen. Zu den geprüften Kriterien gehört das Online Certificate Status Protocol (OCSP), mit dessen Hilfe sich ein Zertifikat auch vor Erreichen des ursprünglich vorgesehenen Ablaufdatums widerrufen lässt.
Besonderes Augenmerk gilt Zertifikaten vom Typ Extended Validation. Hierbei muss der Antragsteller Nachweise erbringen, dass er berechtigt ist, das Zertifikat für eine bestimmte Domain zu beantragen, dass er physisch existiert und eine aktive Organisation unterhält. Das stellt die Identität des Zertifikatinhabers sicher und ob der Betreiber einer Website die im Zertifikat genannte Domain verwenden darf. Die Domain teletrust.de zum Beispiel gehört offenbar tatsächlich TeleTrusT, dem Bundesverband der IT-Sicherheit, weil D-Trust als ausgebende Stelle diesen Zusammenhang sicherlich intensiv geprüft hat.
Ein Teil des Schlüsselpaares, der geheime Schlüssel (Private Key), ist praktisch der Generalschlüssel des Servers und hat einen hohen Schutzbedarf. Er bildet die Basis zum Generieren temporärer Schlüssel, die für den Aufbau genau einer TLS-Verbindung nötig sind.


…