Wie bereits angekündigt werde ich in den nächsten Wochen erläutern, wie man im Java-Ökosystem RMI sicher betrieben kann.

Wie bereits geschildert existieren bei Aufrufen entfernter Objekte per TLS zwei verschiedene Arten von Verbindungen, die abgesichert werden wollen: Zum einen in der Initialisierungsphase die Interaktion mit der Registry und zum anderen nach Erstellen der Verbindung die Kommunikation der Server-Objekte mit den Stubs.

Deswegen besteht die Möglichkeit, beim Erzeugen der Registry eine Server- und eine ClientSocketFactory anzugeben und beim Lookup eine ClientSocketFactory anzugeben. Tut man das, so wird die Interaktion mit der Registry sowohl auf Client- wie auch auf Serverseite verschlüsselt und authentifiziert. Beim Erstellen der eigentlichen Server-Objekte (die von UnicastObject abgeleitet werden) kann man ebenfalls Server- und ClientSocketFactories bei der Konstruktion mitgeben. Das stellt die Verschlüsselung und Authentifizierung während der Kommunikation in der Benutzungsphase sicher wenn Stubs direkt mit Server-Objekten interagieren.

Wichtig in diesem Zusammenhang ist die Tatsache, dass es möglich sein muss, diese Factories zu serialisieren. Das bedeutet zum einen, dass nicht nur die entsprechenden Klassen das Interface Serializable implementieren müssen - auch alle enthaltenen Members müssen dies tun. Außerdem - und das ist eigentlich die wichtigere Information - bedeutet das, dass unter Umständen sensible Informationen (Schlüssel, Passwörter,...) über die Java-Mechanismen serialisiert, übertragen und deserialisiert werden. Eigenimplementierungen dieser Factories sollten daher sehr genau auf Cybersecurity Issues geprüft werden. Es erscheint besser, die bereits in Java mitgelieferten Implementierungen zu nutzen.