[
http://jira.jboss.com/jira/browse/JGRP-372?page=comments#action_12355271 ]
Bela Ban commented on JGRP-372:
-------------------------------
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 with SSL
------------
Key: JGRP-372
URL:
http://jira.jboss.com/jira/browse/JGRP-372
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Critical
Fix For: 2.5
Attachments: ConnectionTableSSL.java, tcp_ssl.jar, TCP_SSL_PROPS.java
From Hal Hildebrand:
Here's the straight TCP version, as I am still working on the handshake
implementation for the TCP_NIO_SSL protocol. This protocol stack element
provides security and authentication (using client side authentication) for
a JGroups TCP stack.
Like the NIO version, this required four minor modifications in the
ConnectionTable 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, TCP_SSL, which one can add to a stack to make
use of it.
As with my previous request, it would be nice to have the changes to
ConnectionTable make it into the mainline, as I currently have to overwrite
the original class to easily implement this. The mods are simple and
innocuous (marked with "HSH").
Right now, the TCP_SSL needs to be configured with an SSLContext. 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 TCP_SSL protocol layer
TCP_SSL protocol = (TCP_SSL) protocolStack.findProtocol("TCP_SSL");
// Create your SSLContext
SSLContext sslContext = ....
// Set up the protocol
protocol.setSslContext(sslContext);
// 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