Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03234.jsonl.gz/606

Der betroffene Dienst (zum Beispiel SMTP) benutzt TLS oder SSL Verschlüsselung und erlaubt, dass der Client die Verbindung neu verhandeln (aufbauen) kann. Hierbei muss der Dienst serverseitig mehr Resourcen aufwenden als der Client. Der Dienst limitiert dabei die Anzahl der Neuverhandlungen nicht. Dies erlaubt dem Client mehrere Verbindungen parallel zum Serverdienst aufzubauen und wiederholend die Verbindungen neu auszuhandeln. Dies kann zu einer Überlastung des Servers und so zu einer Denial of Service führen.
Anleitung
Für dieses Sicherheitsproblem gibt es keine generelle Lösung. Diese Schwachstelle kann überall auftreten, wo ein Dienst mit TLS oder SSL Verschlüsselung zur Verfügung gestellt wird. In fast allen Fällen gibt es keine Möglichkeit, durch eine Konfiguration am Dienst dieses Problem zu beheben. Es ist ein Problem der Implementierung der Verschlüsselung. Welche Versionen der Implementierungen betroffen sind, ist hier aufgelistet: BID-48626, CVE-2011-1473. Es ist empfehlenswert, die betroffene Bibliotheken (zum Beispiel OpenSSL) immer auf den neuesten Stand zu aktualisieren. Falls die Implementierung die Konfiguration der Renegotiation ermöglicht, sollte diese deaktiviert werden.
Hintergrund
Ein SSL/TLS Handshake (Verhandlung der Verschlüsselung) beansprucht mindestens zehn mal mehr Verarbeitungskapazität auf dem Server als auf dem Client. Normalerweise wird ein Handshake nur einmal beim Verbindungsaufbau zum Server durchgeführt. Wenn der Server aber SSL/TLS Renegotiation erlaubt, kann der Client immer wieder eine Renegotiation Anfrage beantragen. Da es den Client viel weniger beansprucht als den Server, kann das mehrfache beantragen von Neuverhandlungen einen Denial of Service hervorbringen. Bei einer solchen Überlastung des Servers, ist es einem anderen Client nicht mehr möglich, die Dienste des Servers zu nutzen.
Der Unterschied dieses Angriffes zu einem verteilten Denial of Service (DDoS) Angriffes ist der, dass es für diesen Angriff weder eine grosse Bandbreite oder zum Beispiel ein Botnetz nötig ist. Ein einziger Client mit einer einzigen TCP/IP Verbindung reicht bereits aus.
Um diese Schwachstelle zu erkennen, kann man manuel wie folgt vorgehen:
openssl s_client -connect ip:port HEAD / HTTP/1.0 R
Eine gute Diskussion zu diesem Thema finden Sie auf: ml ieft.org.