What I’ve been up to:
1. Moved atomic serialization and support for OSGi into AtomicILFactory,
so BasicILFactory functionality effectively remains unchanged. Taking
advantage of the Extensible part of JERI. Note we can also support other
protocols by taking advantage of JERI's extensibility.
2. Newly created TLS RMIServerSocketFactory and RMIClientSocketFactory
utilise the current Subject for credentials to perform TLS handshakes
and connections. This is allows the Registry to be secured for Phoenix,
so Phoenix can run in secure mode, using JERI Secure endpoints for the
ActivationSystem and other components and use the same LoginModule for
both. SSL RMI socket factory's included with the jvm require access to a
KeyStore and don't utilise the Subject. Note that a truststore is still
required. Using the Subject is more flexible and it's extensible with
LoginModule.
a. JERI with secure sockets and atomic serialization can now be utilised
for the following services in Phoenix:
i. ActivationMonitor,
ii. ActivationSystem,
iii. Activator.
b. RMI with TLS sockets for securing:
i. Registry service
ii. LocateRegistry methods.
3. Lots of additional testing using atomic endpoints over JSSE,
transient and activatable configurations for tests.
a. We currently have about 1400 tests, and this is being compounded to
5600 tests with each configuration (there’s more configuration options
so this can go higher eventually). 1400 tests take about 24 hours to
complete, so we’re talking 4 days’ worth of testing for a full run.
4. FindBugs Static testing and more bug fixes.
I’m getting ready to fill out the modular build structure for River and
populate it with River’s code.
Next steps are then to donate externally developed features, module by
module, so people can digest the changes and propose improvements they
want too.
I’m very close to being able to deploy a locked down secure version of
Reggie with TLS and atomic serialization over IPv6, so we can have a
public lookup service permanently running so people can register their
services there, this will be locatable via https unicast and IPv6 Global
multicast. We can then update and modernise the service browser, so
people can experiment with these services.
I’m also thinking we need to set up a small Certificate Authority, so
any user can request a user certificate be signed, and service providers
also. I think we should keep these separate, as users could remain
relatively anonymous, client certificates are only required to prevent
MITM attacks. Services will require more discretion as users will
consume their code, so I think we need a reputation system, where
services that behave badly can be identified and have their certificates
revoked at a Hold level, or revoked irreversibly depending on whether
they rectify the issue with their service.
We could also have different CA signing certs that represent levels of
trust, so you basically start with a minimal level of trust and as you
build up your reputation, you get your certificate signed with CA signer
cert that represents a higher level of trust.
Services will be able to track client certificates, but don’t need to
know any personal details, your private certificate will be your
identity basically.
So what I’m thinking is, we can create a service ecosystem, where we’re
using secure TLS certificates, so companies / people can interact securely.
Regards,
Peter.
