© Sergej Razvodovskij, 123RF

Über Linux, für Admins in Sachen Sicherheit lange ein ruhiger See, sind in letzter Zeit Stürme hinweggefegt, die Namen wie Freak, Beast, Poodle, Shellshock oder Heartbleed trugen. Eine ganze Reihe von ihnen geht auf das Konto von Schwächen in SSL-Bibliotheken. TLS Interposer kann die Wogen glätten.

Der Poodle-Angriff (Padding Oracle On Downgraded Legacy Encryption) fußte auf TLS-Implementierungen, die auf Anfragen von Clients mit neuen TLS-Versionen fatalerweise überhaupt nicht antworteten. Die nahmen daraufhin an, der Server spräche überhaupt kein TLS, und schalteten auf das längst veraltete und verwundbare SSLv3. Angreifer ließen einfach die TLS-Verbindungen vor die Wand laufen und freuten sich, weil der Client SSLv3 hervorkramte.

Auch Heartbleed war ein Implementierungsfehler. Er erlaubte es Angreifern, 64 KByte des Server-Arbeitsspeichers auszulesen – und das mehrfach nacheinander, sodass etwa Zertifikatsschlüssel in falsche Hände gerieten. Bruce Schneier sagte damals, auf einer Katastrophenskala von 1 bis 10 sei dies eine 11.

All das vermeidet der Admin, wenn er die TLS-Implmentierungen auf seinen Servern auf dem aktuellen Stand hält. Was aber, wenn er dort Applikationen betreiben muss, die die neuesten TLS-Versionen gar nicht kennen? So mancher hält nach dem Motto “Never change a running System” stoisch an seinem Apache 2.2 fest oder anderen nur noch archäologisch wertvollen Serverdiensten.

Der Abfänger beim Rocken

Für solche hartnäckigen Netzverschmutzer gibt es den TLS Interposer. Der aktiviert sich über den »LD_PRELOAD« -Mechanismus und fängt dann API-Aufrufe an die Open-SSL-Bibliothek ab. Viele Distributionen haben ihn im Angebot, ansonsten bekommt man ihn bei Github [1] oder auf der DELUG-DVD. Nach dem Entpacken genügt ein »make && sudo make install« – außer dem Compiler bedarf es des Open-SSL-Development-Pakets. Es heißt meist »libssl-dev« oder sehr ähnlich. Wenn der Compiler seine Arbeit getan hat, besitzt der Admin die Datei »libtlsinterposer.so« .

Das Weitere ist recht einfach. Der Admin sorgt dafür, dass der Serverdienst die Umgebungsvariable »LD_PRELOAD« sieht, gefüllt mit dem Pfad zur eben kompilierten Datei »libtlsinterposer.so« . Beim Apache 2.2 zum Beispiel öffne ich dazu die »/etc/apache/envvars« und füge

export LD_PRELOAD=/usr/local/tlsinterposer/libtlsinterposer.so

hinzu. Nach einem Neustart des HTTP-Daemon kommuniziert der greise Apache mit dem jüngsten TLS. Das sollte der Admin aber mit SSL Scan [2] testen oder mit einem der vielen Onlinedienste, die diesen Service anbieten, etwa [3].

Der Autor

Charly Kühnast administriert Unix-Systeme im Rechenzentrum Niederrhein. Zu seinen Aufgaben gehören Sicherheit und Verfügbarkeit der Firewalls und der DMZ.