RE: Re: JMX and SSL

Luis,

Thank you for the information.

My thoughts:
1. I am not sure any 3rd party client can use this method (e.g. MC4J).
There should be a standard way of doing this only by specifying JMX URL,
like you would do on a browser, maybe use 'jndis' instead of 'jndi' in
the URL string. RMI over SSL should be standard, not require custom
socket factories.

2. For boot-strapping reasons, it makes sense that you cannot get client
socket factory from the RMI registry. It also seems to be a security
hole to provide a factory over a non-secure connection to later
establish secure connection, man-in-the-middle comes to mind: a rouge
3rd party modifies or replaces the stub in transit and gets visibility
and control of the SSL connection.

3. I think the other recourse is to require codebase based permission
and to give it to a signed stub. This may be too restrictive and hard to
manage, especially if you don't know where the registry will be.

4. When an unsuspecting JMX user provides SSL protection to its
application he/she may be falling into this same 'trap' thinking the
application is secure, whereas they may unwittingly be subjected to
above security issue.

Regards,
Ron.



-----Original Message-----
From: Luis-Miguel Alventosa [mailto:[email protected]] 
Sent: Monday, September 27, 2004 6:28 AM
Cc: Luis-Miguel Alventosa; Ron Vered; Eamonn McManus; MX4J-Dev (E-mail);
Bordet, Simone
Subject: Re: [Mx4j-devel] Re: JMX and SSL


Hi Ron,

Forget everything I said before! I was completely wrong! Oooops!

The Sun's JNDI/RMI Registry Service Provider does not allow to supply an
SSL RMI Client Socket Factory that would be later used when calling
bind/lookup. This prevents the RMIConnector (client-side) and the
RMIConnectorServer (server-side) to talk to an SSL protected RMI
Registry when going through the JMXConnector[Client|Server]Factory.

There's a possible workaround although a bit more complicated than
calling the factories:

1) Start an SSL-protected RMI Registry (use
LocateRegistry.createRegistry with SSL RMI
    Client and Server Socket Factory)

2) On the server side, instantiate the RMIJRMPServerImpl explicitly and
pass it in to
    the RMIConnectorServer's constructor which takes an RMIServerImpl as
argument, then
    bind the RMIJRMPServerImpl explicitly to your SSL-protected RMI
Registry
    (use LocateRegistry.getRegistry with SSL RMI Client Socket Factory).

3) On the client side, retrieve the RMIServer stub from the
SSL-protected RMI Registry
    (use LocateRegistry.getRegistry with SSL RMI Client Socket Factory)
and then pass it
    in to the RMIConnector constructor.

Regards,
Luis

 > Luis-Miguel Alventosa wrote:
 >
 > Hi Ron,
 >
 > When you specify the SSL RMI Socket Factories in the
RMIConnectorServer  > map,  > SSL is only used for the RMI invocations
on the RMIServer and RMIConnection  > remote objects.  >  > In order to
perform SSL on the JNDI lookup you have to create your RMI  > registry
> by supplying the SSL RMI Socket Factories too. The client application
will  > then use SSL to carry out the JNDI lookup.  >  > See
java.rmi.registry.LocateRegistry.createRegistry(int port,  >
RMIClientSocketFactory csf,  > RMIServerSocketFactory ssf)  >  >
Regards,  > Luis  >  >  > Ron Vered wrote:  >  >  >  > Eamonn,  >  >  >
> This is with regard to RMI transport, specifically RMI JNDI.  >  >  >
> When a JMX client connects to JMX server (in above scenario), there
are  >  > actually 2 connections made, 1 to the RMI naming service and
the other  >  > to the exported RMI object.  >  > While there is a way
to provide socket factories for RMI transport for  >  > the exported RMI
object, I am not aware of a way to specify socket  >  > factories for
the JNDI lookup.  >  >  >  > If I am not mistaken, you need to specify
socket factory on the client  >  > before you do the lookup since it's a
boot-strap issue.  >  >  >  > If SSL is required for both the JNDI
lookup and for the RMI invocation  >  > (and not only for the latter
connection), how can this be done?  >  >  >  > Regards,  >  > Ron.


------------------------------------------------------------------------------
This e-mail message is for the sole use of the intended recipient(s) and contains confidential and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners.  Any unauthorized review, use, copying, disclosure or distribution of this message is strictly prohibited.  If you are not an intended recipient of this message, please contact the sender by reply e-mail and destroy all soft and hard copies of the message and any attachments.  Thank you for your cooperation.
====================================================



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php