Standalone EJB Client & SSL - not fully encrypted

[glassfishrobot]

I would like ALL comms between a Standalone-EJB-client and the GF server to be entirely encrypted.

Currently, using the settings:

required required

partially solves the problem, but there is still some unencrypted traffic on port 3700.

This has been discussed in http://forums.java.net/jive/thread.jspa?threadID=75841&tstart=0 and, but there is as yet no solution and the only promising idea is use of AppClient.

I would like a way of doing this using a standalone client (not AppClient)

Without a solution, it seems that it is not possible to use a standalone-EJB-client without risk that someone will sniff the unencrypted traffic on port 3700. They might not be able to see your data (that should be encrypted - forced by the above config), but (I think) they will be able to see what objects you are looking up.

Thanks for looking at this.

Environment

Operating System: All Platform: Linux URL: http://forums.java.net/jive/thread.jspa?threadID=75841&tstart=0

Affected Versions

[V3]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/11647
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @vbkumarjayanti
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented kumara said: Approved for 3.0.1

[glassfishrobot]

@glassfishrobot Commented nitkal said: This issue has now been fixed in v3 for both the appclient and the standalone client cases. For the appclient, the sun-acc.xml should have a security element to indicate a secure client connection. For the standalone client, a system property : com.sun.CSIV2.ssl.standalone.client.required=true needs to be passed so that a SSL handshake is requested by the client.

[glassfishrobot]

@glassfishrobot Commented ajvok said: Thank you for looking at this issue. I have run into trouble using the fix.

I have re-opened this issue & apologise if it is my stupidity that is preventing this from working.

Any advice much appreciated.

=====================================

Using Nightly Build from Mar 29.

While trying to get this working I'm also running the following command to watch what is being sent to ports 3700 & 3820: tcpdump -i any -p -s 0 dst port 3820 or 3700

Run previous version of my client program, with the new GlassFish build: tcpdump reports activity on both 3820 & 3700. This is as expected and represents the issue at hand (i.e. we don't want activity on 3700). Client program completes successfully.

Add the line: System.setProperty("com.sun.CSIV2.ssl.standalone.client.required","true");

Run again: Activity only on 3700. Program fails.

Add the line: System.setProperty("javax.net.debug", "all");

Run again: It looks my client is trying to make an SSL connection on the non-SSL 3700.

Add the line: props.setProperty("org.omg.CORBA.ORBInitialPort", "3820");

Run again: Still only activity on 3700.

Change the server config so that 3700 uses SSL rather than plaintext: For orb-listener-1, tick 'security enabled' and save. Remove the line: props.setProperty("org.omg.CORBA.ORBInitialPort", "3820");

Run again: Still only activity on 3700 (Expected). Program fails. Looks like 3700 is still a plaintext port.

Restart the server - make sure previous orb config has taken hold.

Run again: no difference.

Look again at the server config. On orb-listener-1, see the SSL tab. Change the certificate nickname from blank to s1as (same as for the SSL listener). Save & restart the server. The server fails to start.

Am I missing some simple config trick in either the client or the server?

Where do I go from here?

Thanks.

[glassfishrobot]

@glassfishrobot Commented ajvok said: Another half hour messing with this has produced a result.

Previously I was doing this:

props.setProperty("org.omg.CORBA.ORBInitialPort", "3820"); Context ctx = new InitialContext(props);

But when I replace the first line with: System.setProperty("org.omg.CORBA.ORBInitialPort", "3820");

...all is well.

Now, I only have activity on port 3820 and the program completes successfully.

That wraps it up for me.

Thank you for resolving this issue so promptly.

[glassfishrobot]

@glassfishrobot Commented dhirup said: Closing this bug as the fix was verified by submitter

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-11647

[glassfishrobot]

@glassfishrobot Commented Reported by ajvok

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Monday, June 14th 2010, 9:12:56 am