Issue Details (XML | Word | Printable)

Key: GLASSFISH-11647
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: kumarjayanti
Reporter: ajvok
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Standalone EJB Client & SSL - not fully encrypted

Created: 04/Mar/10 06:28 PM   Updated: 14/Jun/10 04:12 PM   Resolved: 14/Jun/10 04:12 PM
Component/s: security
Affects Version/s: V3
Fix Version/s: v3.0.1

Time Tracking:
Not Specified


Issuezilla Id: 11,647
Tags: v3_0_1_approved
Participants: ajvok, Dhiru Pandey, kumara, kumarjayanti and Nithya Ramakrishnan

 Description  « Hide

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

Currently, using the settings:


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

This has been discussed in 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.

kumara added a comment - 08/Mar/10 01:19 PM

Approved for 3.0.1

Nithya Ramakrishnan added a comment - 25/Mar/10 04:38 AM

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.

ajvok added a comment - 29/Mar/10 08:58 PM

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:

Run again: Activity only on 3700. Program fails.

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

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

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?


ajvok added a comment - 29/Mar/10 10:23 PM

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.

Dhiru Pandey added a comment - 14/Jun/10 04:12 PM

Closing this bug as the fix was verified by submitter