4 a.m.
[ http://jira.jboss.com/jira/browse/JGRP-371?page=comments#action_12355272 ]
Bela Ban commented on JGRP-371:
-------------------------------
Okay, I looked at SSL support in JGroups, and found out the following (I included the old
thread below for reference).
In JDK 5, SSL can be either implemented via SSLSockets/SSLServerSockets or via SSLEngine.
The former method is tied to java.net.{Server}Sockets, the latter is not tied to any
specific transport.
SSLEngine is essentially what is recommended by SUN, as it accommodates any IO model
(blocking / non-blocking), threading model and *transport*. So, the advantage of SSLEngine
is that it can be used both for TCP and TCP_NIO, and it could be used even over UDP.
HOWEVER, there are issues with using SSLEngine in a cluster environment:
* Cost: since an SSLEngine is still point-to-point, there has to be
one session per peer connection. So, for 10 nodes in the cluster,
this means (n-1) * (n-1) sessions (if everybody sends data): 81
sessions. It is not just the 81 sessions, but also the initial
cost to set those sessions up (SSL handshaking)
* Okay, we could set up SSLEngine to use shared passwords, but I'm
not sure this is a good idea !
* SSLEngine is very similar to the JGroups ENCRYPT protocol, except
that ENCRYPT was written with clusters in mind:
o it establishes 1 cluster session (rather than 81) with a
shared cluster-wide key
o for new nodes joining, or leaving/crash of existing nodes,
the shared key is recomputed and distributed to existing
members. New members will use public/private encryption to
join the group and only then get the shared key
* In summary, SSLEngine does what ENCRYPT does, but less efficiently !
TCP_NIO with SSL
----------------
Key: JGRP-371
URL: http://jira.jboss.com/jira/browse/JGRP-371
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Scott Marlow
Priority: Critical
Fix For: 2.5
Attachments: ssl-nio.jar
From Hal Hildebrand:
Attached are the sources to allow a new protocol stack which uses SSL over
NIO. This protocol stack element provides security and authentication
(using client side authentication) for a JGroups TCP stack using NIO.
This required two minor modifications in the ConnectionTableNIO class.
These modifications allow one to subclass to create a connection table which
uses SSL for the connections. Finally, there is a new protocol stack
element, SSL_NIO, which one can add to a stack to make use of it.
Regardless of whether this makes it into the codeline of JGroups, it would
be nice to have the changes to ConnectionTableNIO make it into the mainline,
as I currently have to overwrite the original class to easily implement this
- the last thing I want to do is fork ConnectionTableNIO ;) I'd rather just
subclass it. The mods are simple and innocuous (marked with "HSH").
Right now, the SSL_NIO needs to be configured with an SSLSocketFactory. I
didn't bother with integrating with the normal JGroups mechanism using
properties from the configuration because I consider it inherently insecure
to ensconce my passwords in configuration files. But the changes to enable
this are straight forward. Currently, to configure the factory for the
protocol layer, do something like the following before connecting your
channel:
// Construct your Jchannel
JChannel jchannel = ...
// Access your protocol stack
ProtocolStack protocolStack = jchannel.getProtocolStack();
// Retrieve the SSL_NIO protocol layer
SSL_NIO protocol = (SSL_NIO) protocolStack.findProtocol("SSL_NIO");
// Create your SSLSocketFactory
SSLSocketFactory socketFactory = ....
// Set up the protocol
protocol. SetSocketFactory(socketFactory);
// Connect your channel
jchannel.connnect("my-group");
Cheers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira