Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Glassfish ORB does not work with SSL sockets #26

Open
glassfishrobot opened this issue Aug 7, 2018 · 11 comments
Open

Glassfish ORB does not work with SSL sockets #26

glassfishrobot opened this issue Aug 7, 2018 · 11 comments

Comments

@glassfishrobot
Copy link

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)
- waiting to lock <0x00000000e31f7718> (a sun.security.ssl.SSLSocketImpl)
at com.sun.corba.ee.impl.transport.ConnectionImpl.write(ConnectionImpl.java:487)
at com.sun.corba.ee.impl.encoding.CDROutputObject.writeTo(CDROutputObject.java:225)
at com.sun.corba.ee.impl.transport.ConnectionImpl.sendWithoutLock(ConnectionImpl.java:758)
at com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:146)
at com.sun.corba.ee.impl.encoding.BufferManagerWriteStream.sendMessage(BufferManagerWriteStream.java:160)
at com.sun.corba.ee.impl.encoding.CDROutputObject.finishSendingMessage(CDROutputObject.java:199)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.finishSendingRequest(MessageMediatorImpl.java:254)
at com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.marshalingComplete1(ClientRequestDispatcherImpl.java:398)
at com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.marshalingComplete(ClientRequestDispatcherImpl.java:365)
at com.sun.corba.ee.impl.protocol.ClientDelegateImpl.invoke(ClientDelegateImpl.java:259)
at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:491)
[...]
at org.example.OurClientApplication.main(OurClientApplication.java:354)

"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)
- locked <0x00000000e31f7718> (a sun.security.ssl.SSLSocketImpl)
at sun.security.ssl.SSLSocketImpl$AppInputStream.read(java.base@11-ea/SSLSocketImpl.java:602)
- locked <0x00000000e2f47a18> (a sun.security.ssl.SSLSocketImpl$AppInputStream)
at com.sun.corba.ee.impl.transport.ConnectionImpl.readFully(ConnectionImpl.java:461)
at com.sun.corba.ee.impl.transport.ConnectionImpl.read(ConnectionImpl.java:421)
at com.sun.corba.ee.impl.transport.ConnectionImpl.createMessageMediator(ConnectionImpl.java:382)
at com.sun.corba.ee.impl.transport.ConnectionImpl.readBits(ConnectionImpl.java:332)
at com.sun.corba.ee.impl.transport.ConnectionImpl.read(ConnectionImpl.java:324)
at com.sun.corba.ee.impl.transport.ReaderThreadImpl.doWork(ReaderThreadImpl.java:113)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)

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.

@glassfishrobot
Copy link
Author

@avl42
Copy link

avl42 commented Apr 26, 2019

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.

@rwaterma
Copy link

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 .

@avl42
Copy link

avl42 commented Apr 29, 2019

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?

@rwaterma
Copy link

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.

@russgold
Copy link
Contributor

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.

@avl42
Copy link

avl42 commented Apr 29, 2019

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.)

@russgold
Copy link
Contributor

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.

@avl42
Copy link

avl42 commented Apr 29, 2019

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.)

@russgold
Copy link
Contributor

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.

@avl42
Copy link

avl42 commented Mar 24, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants