[
https://jira.jboss.org/jira/browse/JBAS-5815?page=com.atlassian.jira.plug...
]
Stefan Guilhen commented on JBAS-5815:
--------------------------------------
Extending RMISSLServerSocketFactory would never be a solution because this factory
internally uses the DomainServerSocketFactory as a delegate. The real issue here is that
when you do
<mbean code="org.jboss.invocation.jrmp.server.JRMPInvoker"
name="jboss:service=invoker,type=jrmp,socketType=SSLSocketFactory,wantsClientAuth=true">
<attribute name="RMIObjectPort">0</attribute>
<attribute
name="RMIClientSocketFactory">org.jboss.security.ssl.RMISSLClientSocketFactory
</attribute>
<attribute name="RMIServerSocketFactoryBean"
attributeClass="org.jboss.security.ssl.RMISSLServerSocketFactory"
serialDataType="javaBean">
<property
name="bindAddress">${jboss.bind.address}</property>
<property
name="securityDomain">java:/jaas/rmi-ssl</property>
<property name="wantsClientAuth">true</property>
<property name="needsClientAuth">true</property>
<property
name="CiperSuites">TLS_DHE_DSS_WITH_AES_128_CBC_SHA</property>
<property
name="Protocols">SSLv2Hello,SSLv3,TLSv1</property>
</attribute>
</mbean>
the securityDomain property must be handled by the SecurityDomainEditor. Absence of this
editor will cause the security domain to be null and this is the root of the NPE that has
been reported. In other words, when a JRMPInvoker is configured using SSL, the
SecurityDomainEditor must be available. However, this doesn't happen when the
configuration of the JRMPInvoker is done in conf/jboss-service.xml. Reason:
- SecurityDomainEditor is installed by JaasSecurityManagerService's startService()
method. This MBean is located in conf/jboss-service.xml.
- The MBeans configured in this file are first instantiated, and then started according to
their dependencies.
- When the JRMPInvoker is instantiated, it tries to use the SecurityDomainEditor to get to
the SecurityDomain instace that must be used. This editor is not yet available because
JaasSecManagerService has been instantiated but not yet started. As a result, a null
security domain is set in RMISSLServerSocketFactory.
A workaround for this would be to configure the JRMPInvoker somewhere else, like
deploy/jrmp-invoker-service.xml. This works because when this file gets processed,
JaasSecurityManagerService will already have been created and started - and consequently,
SecurityDomainEditor will have been installed.
Bug in DomainServerSocketFactory - SSL clientAuth
--------------------------------------------------
Key: JBAS-5815
URL:
https://jira.jboss.org/jira/browse/JBAS-5815
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security
Reporter: Scott M Stark
Assignee: Stefan Guilhen
Fix For: JBossAS-5.0.0.GA
Daniel Straub <ds(a)ctrlaltdel.de> reports:
I had to enable some settings on the RMISSLServerSocketFactory, but the solution for this
- shown in
wiki.jboss.org/wiki/JRMPInvoker or JBAS-1983 doesn't work. This ends with a
nullpointer exception because the the initialization of securityDomain failed.
To deal with this, I derive a class from the RMISSLServerSocketFactory like this
public class ServerSocketFactory extends RMISSLServerSocketFactory {
public ServerSocketFactory() {
super();
setNeedsClientAuth(true);
//setWantsClientAuth(false);
}
}
and use this as RMIServerSocketFactory of the JRMPInvoker. But this solution also
doesn't work ;-(
There is another problem in the DomainServerSocketFactory :
public ServerSocket createServerSocket(int port, int backlog, InetAddress ifAddress)
throws IOException
{
initSSLContext();
SSLServerSocketFactory factory = sslCtx.getServerSocketFactory();
SSLServerSocket socket = (SSLServerSocket) factory.createServerSocket(port, backlog,
ifAddress);
SSLSessionContext ctx = sslCtx.getServerSessionContext();
System.out.println(ctx);
if( log.isTraceEnabled() )
{
String[] supportedProtocols = socket.getSupportedProtocols();
log.debug("Supported protocols: " +
Arrays.asList(supportedProtocols));
String[] supportedCipherSuites = socket.getSupportedCipherSuites();
log.debug("Supported CipherSuites: " +
Arrays.asList(supportedCipherSuites));
}
socket.setNeedClientAuth(needsClientAuth);
socket.setWantClientAuth(wantsClientAuth);
...
- to make a long story short, the "bug" is in the implementation of
SSLServerSocket.
This class uses only one instance variable to store the setting of clientAuth
("doClientAuth").
socket.setNeedClientAuth(needsClientAuth) set these to the value "2". fine.
but the next call socket.setWantClientAuth(wantsClientAuth) set these to "1" if
wantsClientAuth is true, otherwise to "0".
in both cases, the first call is override. bad.
Here is the decompiled class (com.sun.net.ssl.internal.ssl. SSLServerSocketImpl) :
...
public void setNeedClientAuth(boolean flag) {
doClientAuth = ((byte)(flag ? 2 : 0));
}
public boolean getNeedClientAuth() {
return doClientAuth == 2;
}
public void setWantClientAuth(boolean flag) {
doClientAuth = ((byte)(flag ? 1 : 0));
}
public boolean getWantClientAuth() {
return doClientAuth == 1;
}
...
well, what for a strange implementation ...
I modified my ServerSockeFactory >
@Override
public ServerSocket createServerSocket(int port) throws IOException {
SSLServerSocket sslSocket = (SSLServerSocket) super.createServerSocket(port);
sslSocket.setNeedClientAuth(true);
return sslSocket;
}
and now the client authentification works. But can we provide a fix for this problems
(initialization of RMISSLServerSocketFactory and SSLServerSocket - e.g if needsClientAuth,
why set also wantsClientAuth) ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira