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
Operations

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

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

Environment:

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:

<ior-security-config>
<transport-config>
<integrity>required</integrity>
<confidentiality>required</confidentiality>
</transport-config>
</ior-security-config>

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.



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:
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.
===========================================


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