Open glassfishrobot opened 6 years ago
Just wondering, if this is "work in progress", or whether SSLIOP is just not implemented with glassfish, or if it can be done with some custom code... Having client side working would already help me a lot.
It can be done with custom code. Implement your own com.sun.corba.ee.spi.transport.ORBSocketFactory, and use the sockets from https://github.com/baswerc/niossl .
I may have misunderstand parts, or miss other stuff that you thought went without saying, but isn't SSLIOP a little bit different from just IIOP with ssl-sockets? iiuc, an ssl-capable Server provides an IOR string, that contains a plain IIOP socket (on which the server will always send some "no permission" error), and a second port on where it "expects ssl-sockets".
If I were to just ssl'ify the socket, it would probably still hit the wrong ("no perms") port, and even fail to negotiate ssl. How will I tell glassfish to consider the ssl-parts of the IOR and use the ssl-port specified in the IOR ? Or do I need to extract the real ssliop port from the ORB, myself?
JacORB (back in Java 8 times) did include some SSLSocketFactory that I could use by merely setting some properties. Any chance that Glassfish will offer a standard SSL-capable ORBSocketFactory?
That's indeed another issue of IIOP over SSL, but not subject of this bug report.
AFAIK, there is no way to negotiate SSL between client and server. In our software we control both, client and server, and while the IOR only reveals the clear text port, our client is aware of a corresponding ssl port and uses it in favor of the clear text port. But that's how we handled it ever since, while the socket implementation problem arose with the switch from the JDK builtin ORB to the Glassfish ORB.
The Glassfish ORB was originally written before CORBA added a standard means of using SSL (which, as you note, includes both plaintext and SSL ports), and the server should return an IOR with the appropriate port for objects which are SSL-only; however, there would be an awful lot of work involved to implement that, including some serious rework to address good use of NIO, which is related to performance issues. I estimate that as several man-months of work. I had started down that path several years ago, but business priorities changed.
Is NIO needed for glassfish internally, or will I be able to use plain SSLSockets, if my use of Corba is purely synchronous? (my app always waits for an answer; no NIO in my code.)
The ORB uses NIO internally, although with hacks to make it effectively synchronous (that's a major part of what needs to be cleaned up). As rwaterma noted, you can add SSL by creating your own ORBSocketFactory implementation, or using an existing one.
I wasn't yet successful in finding an existing one. (the only apparently relevant result for my search for glassfish, orb and ssl so far was this very thread here.)
There is some support for IIOP over SSL here, apparently. At least the CTS has supported CSIv2 tests for years, using this ORB - that means that it must work. I suspect that some of the relevant logic is in Glassfish itself.
Oh, it's been a while since then. In the meantime I shuffled together some glassfish jars plus some jacorb jars, and it somehow luckily worked. -- To be a bit more precise: I added the JacOrb jars, and checked for unloadable classes, then looked which glassfish jar files contained these, until the process converged.
We are trying to use the Glassfish ORB (version 4.2.0-b003) with SSLSockets, by setting the com.sun.corba.ee.legacy.connection.ORBSocketFactoryClass property to an according custom factory. This leads to a problem on the client side. As a matter of fact, an SSLSocket has no SocketChannel. For sockets without a channel the ORB sets the useSelectThreadToWait flag to false (com.sun.corba.ee.impl.transport.ConnectionImpl#defineSocket). This causes the creation of an extra thread that blocks our main thread:
"main" #1 prio=5 os_prio=0 cpu=2423,90ms elapsed=42,16s tid=0x00007f9a50017000 nid=0x4698 waiting for monitor entry [0x00007f9a58aa5000] java.lang.Thread.State: BLOCKED (on object monitor) at sun.security.ssl.SSLSocketImpl.getOutputStream(java.base@11-ea/SSLSocketImpl.java:667)
"p: default-threadpool; w: 1" #24 daemon prio=5 os_prio=0 cpu=1,87ms elapsed=39,39s tid=0x00007f9a51cac800 nid=0x46c4 runnable [0x00007f99a251d000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(java.base@11-ea/Native Method) at java.net.SocketInputStream.socketRead(java.base@11-ea/SocketInputStream.java:115) at java.net.SocketInputStream.read(java.base@11-ea/SocketInputStream.java:168) at java.net.SocketInputStream.read(java.base@11-ea/SocketInputStream.java:140) at sun.security.ssl.SSLSocketInputRecord.read(java.base@11-ea/SSLSocketInputRecord.java:464) at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(java.base@11-ea/SSLSocketInputRecord.java:70) at sun.security.ssl.SSLSocketImpl.readRecord(java.base@11-ea/SSLSocketImpl.java:839)
In this state, our application hangs forever.
We can reproduce this effect even easier, without a custom socket factory, just by setting com.sun.corba.ee.transport.ORBUseNIOSelectToWait to false.