IT-Monitoring: OpenNMS macht Netzwerke zuverlässiger

In letzter Zeit haben uns mehrere Support-Anfragen zu demselben Problem erreicht: Eine TLS/SSL-gesicherte Verbindung kommt nicht zustande. Dieser Artikel soll mögliche Ursachen und Lösungsmöglichkeiten aufzeigen.

Zum besseren Verständnis: Eine kurze Einführung in TLS/SSL

TLS steht für „Transport Layer Security“ und ist ein Protokoll, mit dem TCP-Verbindungen abgesichert werden. Es bietet auf einer TCP-Verbindung eine Ende-zu-Ende Verschlüsselung an, sorgt für Datenintegrität (stellt also sicher, dass übertragene Nachrichten nicht verändert werden) und ermöglicht eine gegenseitige Authentifizierung der Kommunikationspartner mit Hilfe von Zertifikaten. Entwickelt wurde es vom Unternehmen „Netscape Communications“ unter dem Namen „SSL“ (Secure Socket Layer) und wird seit der Version „SSL3“ unter dem Namen TLS standardisiert und weiterentwickelt. Die aktuelle Version ist TLSv1.2.

Eine mit TLS abgesicherte Verbindung wird mit Hilfe eines Handshakes aufgebaut. Hierbei durchlaufen Server und Client folgende Aufgaben:

  • Überprüfung des Server-Zertifikats durch den Client
  • optional: Überprüfung des Client-Zertifikats durch den Server
  • Einigung auf die verwendete  TLS/SSL-Version
  • Einigung auf ein gemeinsames Verschlüsselungs- und Signaturverfahren (Cipher-Suite)
  • Generierung eines gemeinsamen geheimen Schlüssels (Master-Key) für die Session

Der Handshake startet mit der Nachricht Client Hello, die der Client an den Server sendet. Hierbei enthalten ist unter anderem die höchste SSL/TLS-Version, die der Client unterstützt, sowie eine Liste der durch den Client unterstützten Verschlüsselungs- und Signaturverfahren (sogenannte „Cipher-Suites“). Der Server antwortet daraufhin mit der Nachricht Server Hello, die die verwendete Cipher Suite und SSL/TLS-Version, die für die Verbindung verwendet werden soll, enthält. In einer weiteren Nachricht sendet der Server sein SSL/TLS-Zertifikat an den Client, das vom Client überprüft wird. Anschließend findet die Aushandlung eines gemeinsamen geheimen Schlüssels statt, der für die Verbindung verwendet werden soll. Nach Abschluss des Handshakes wird mit einer Nachricht auf die ausgehandelte Cipher Suite gewechselt und die weitere Verbindung findet verschlüsselt statt.

Mögliche Probleme

Kommt eine per TLS/SSL gesicherte Verbindung nicht zustande, kann dies unter anderem folgende Ursachen haben:

  • Die TCP Verbindung zum Server und dem entsprechenden Port ist nicht möglich
  • Das Serverzertifikat konnte durch den Client nicht verifiziert werden
  • Die Einigung auf eine gemeinsame Cipher Suite war nicht erfolgreich
  • Die Einigung auf eine gemeinsame TLS/SSL-Version war nicht erfolgreich

Gerade der letzte Punkt – die Einigung auf eine gemeinsame TLS/SSL-Version – ist nach Bekanntwerden der Sicherheitslücke Poodle und dem Deaktivieren bestimmter SSL-Versionen in unserem Umfeld häufig aufgetreten. Auf dem Server werden dabei ältere SSL-Versionen (in der Regel SSLv2 und SSLv3) deaktiviert. Ein TLSv1.2 Client, der neben der aktuellen Version auch noch SSLv2 unterstützen möchte, muss nach dem RFC5246 die Nachricht Client Hello im Handshake selbst in der Version SSLv2 senden (http://tools.ietf.org/html/rfc5246#appendix-E.2). Der Server muss diese Nachricht entgegennehmen und verarbeiten, auch wenn er selbst SSLv2 für die spätere Verbindung nicht zulassen möchte. In einigen Projekten und Supportanfragen gab es in der letzten Zeit aus diesem Grund einen Handshake Failure – die TLS-Verbindung kam nicht zustande.

Analysemöglichkeiten

Um eine fehlerhafte Verbindung zu analysieren, gibt es verschiedene Möglichkeiten:

  • Überprüfung des Aufbaus der TCP-Verbindung (telnet)
  • Überprüfung des Aufbaus der TLS-Verbindung (openssl s_client)
  • Weitere Überprüfung mit wireshark

Zuerst kann geprüft werden, ob überhaupt eine TCP-Verbindung vom Client zum Server aufgebaut wird. Dies kann mit dem Tool telnet geschehen. Folgender Befehl testet den Verbindungsaufbau zu einem Server (in unserem Beispiel 10.9.24.11 auf Port 443):

root@test1:~# telnet 10.9.24.11 443
Trying 10.9.24.11...
Connected to 10.9.24.11.
Escape character is '^]'.

Erhält man die oben stehende Ausgabe, hat der Verbindungsaufbau funktioniert. Im Falle einer unverschlüsselten Verbindung könnte man nun direkt mit der jeweiligen Anwendung auf dem Server kommunizieren.

 

Der Aufbau der TLS-Verbindung mit dem Handshake kann mit dem Tool openssl s_client getestet werden. Folgender Befehl stellt eine TLS-gesicherte Verbindung zu einem Server her:

openssl s_client -connect 10.9.24.11:443

Hiermit kann man testen, ob der TLS-Handshake richtig durchgeführt wird. Kommt eine Verbindung zustande, lässt sich das Tool anschließend wie Telnet verwenden und man kann direkt mit der jeweiligen Anwendung auf dem Server kommunizieren.

 

Kommt hierbei keine Verbindung zustande, gibt die Ausgabe des Tools gegebenfalls Hinweise auf die Ursache. Um zu überprüfen, ob die Einigung auf eine gemeinsame SSL/TLS-Version nicht möglich ist, kann man durch die Angabe eines Parameters eine bestimmte SSL/TLS-Version erzwingen:

openssl s_client -connect 10.9.24.11:443 -ssl2
openssl s_client -connect 10.9.24.11:443 -ssl3
openssl s_client -connect 10.9.24.11:443 -tls1

Kommt mit TLSv1 als erzwungene Version nun eine Verbindung zustande, lässt sich das Problem vermutlich darauf zurückführen, dass der Server keine SSLv2 Client Hello Messages untersützt.

 

Weitere Analysen lassen sich mit dem Mitschneiden von Netzwerktraffic mit den Tools tcpdump / Wireshark durchführen. Mit folgendem Befehl werden die Pakete vollständig mitgeschnitten und in eine Ausgabedatei geschrieben:

tcpdump -s 0 -w output.pcap

Die mitgeschnittenen Pakete lassen sich anschließend mit dem Tool Wireshark genauer ansehen und analysieren.

Lösungsansätze

Je nach ermittelter Ursache sollte zunächst die Serverkonfiguration überprüft werden. Folgende Fragen sollte man dabei durchgehen:

  • Problem: Das Serverzertifikat konnte durch den Client nicht verifiziert werden.
    • Ist das Zertifikat noch gültig?
    • Ist das Zertifikat für den Host ausgestellt?
    • Ist das Zertifkat von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt?
  • Problem: Die Einigung auf eine gemeinsame TLS/SSL-Version war nicht erfolgreich.
    • Sind alte SSL-Versionen (SSLv2 und SSLv3) deaktiviert?
    • Wird SSLv2 Client Hello unterstützt?

Manchmal hat man keine Möglichkeit, die Konfiguration des Servers zu verändern. Dann gibt es folgende Möglichkeiten:

  • Problem: Das Serverzertifikat konnte durch den Client nicht verifiziert werden.
    • Verifizierung des Servers deaktivieren.
  • Problem: Die Einigung auf eine gemeinsame TLS/SSL-Version war nicht erfolgreich.
    • Eine bestimmte SSL/TLS-Version im Client zu erzwingen.

 Weiterführende Links

Schreibe einen Kommentar

Benötigte Felder sind mit * markiert.