Wie bereits angekündigt werde ich in den nächsten Wochen einige Aspekte asymmetrischer Kryptographie beschreiben. Der vorliegende Artikel erläutert die Absicherung von Javas Remote Method Invocation (RMI).

Egentlich sollte es ja hier um asymmetrische Krypto gehen - RMI hat zunächst erst einmal nichts damit zu tun. Aber da RMI Remote Method Invocation bedeutet und es dabei darum geht, dass Objekte in unterschiedlichen Prozessen - die auch auf physisch verschiedenen, nur durch Netzwerk verbundenen - Rechnern ausgeführt werden miteinander interagieren und sich zum Beispiel gegenseitig aufrufen ist Cybersecurity eben inzwischen auch hier ein Thema.

Nun könnte man naiv herangehen und sagen: wenn zwei Prozesse miteinander Daten austauschen, kann man einfach einen TLS-Tunnel bauen und schon ist die Herausforderung keine mehr. Mit RMI ist das aber nicht so einfach: Zunächst erst einmal reden nicht die Prozesse miteinander, sondern die Objekte oder Instanzen: Je zwei davon öffnen eine Socketverbindung. Das heißt, dass sich zwischen zwei beliebigen RMI-Anwendungen sowohl die Anzahl von Verbindungen als auch die verwendeten Ports unterscheiden (können). Damit fällt die Idee eines Tunnels aus.

Hier zunächst einmal ein Diagramm, das einen Überblick über die komplexen Interaktionen in RMI-Anwendungen geben soll:

Zunächst muss der Serverprozess einmal Objekte zur Verfügung stellen, mit denen andere Prozesse interagieren sollen [1]. Diese Objekte müssen dann bei einer Registry publiziert werden [2]. So können Clientprozesse diese auffinden [3] und internen einen Stub erzeugen [6], mit dem der Client-Prozess redet [7] und der transparent die Kommunikation mit dem Server-Objekt übernimmt [8] und [9]. Zur Erstellung des Stubs ist es eventuell nötig, den Code für Klassen nachzuladen, der in der Clientanwendung nicht zur Verfügung steht (4) und (5). Daher gibt es bei RMI die Möglichkeit, einen Class-Server bereitzustellen, von dem die fehlenden Klassen nachgeladen werden können.

Fassen wir also zusammen, was alles per TLS abgesichert werden muss, um heutigen Erwartungen zum Stand der Technik zu genügen: Die Verbindungen zur Registry (im Diagramm rot gekennzeichnet) müssen ebenso abgesichert werden wie die zum Server, von dem fehlende Klassen nachgeladen werden sollen (im Diagramm blau) und die Verbindungen zwischen Server-Objekten und Stubs (im Diagramm grün). Das sind insgesamt drei Kommunikationskanäle.

Der erste ist der einfachste der drei: Der Server, der die Klassen zur Verfügung stellt kann als simpler HTTPS-Server realisiert werden.

Ein wenig mehr Aufwand und Planung benötigt die Absicherung der Kommunikation zwischen den Server-Objekten und den Stubs. Hier muss man zwei SSL SocketFactories bereitstellen (Client und Server authentifizieren sich jeweils über ihre Schlüssel und Zertifikate).

Das schwierigste Problem ist die Absicherung der Kommunikation mit der Registry: Der Lookup und die Registrierung von Objekten kann direkt über die API der Registry erfolgen oder alternativ (und im Mischbetrieb) via JNDI. Allerdings habe ich noch keine Möglichkeit gefunden, den Lookup per JNDI so zu konfigurieren, dass er TLS benutzt - hier wird immer unverschlüsselt kommuniziert. Da man eine Registry nur entweder plain oder TLS starten kann, funktioniert der Lookup über JNDI dann mit einer TLS-Registry nicht mehr. Man muss also - besonders wenn man bestehende RMI-Anwendungen per TLS absichern möchte genau nachsehen, ob der Lookup ausschließlich per Registry erfolgt, oder Teile der Anwendung dafür auf JNDI zurückgreifen. In diesem Fall muss man ein entsprechendes Refactoring einplanen oder die Kommunikation mit der Registry zähneknirschend erst einmal weiter unverschlüsselt belassen

Damit ist der Inhalt der folgenden Artikel in dieser Serie geklärt:

• Sicheres Nachladen von Klassen aus einer JVM in eine andere mittels dediziertem HTTPS-Server
• Kommunikation zwischen Server-Objekten und Stubs abgesichert per TLS
• Betrieb einer mittels TLS abgesicherten Registry
• Refactoring von JNDI hin zu direkter Benutzung der Registry für Binding und Lookup in der OpenSource Bibliothek t(ransparent)RMI

Artikel, die hierher verlinken