jboss-remoting-issues July 2012

jboss-remoting-issues@lists.jboss.org

1 participants
14 discussions

[JBoss JIRA] (JBREM-1306) Remoting tries to create SSLSocketFactory even when not desired

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1306?page=com.atlassian.jira.plugin... ] Ron Sigal commented on JBREM-1306: ---------------------------------- Changes committed to branches 2.2 and 2.x. Need to update documentation. > Remoting tries to create SSLSocketFactory even when not desired > --------------------------------------------------------------- > > Key: JBREM-1306 > URL: https://issues.jboss.org/browse/JBREM-1306 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.4, 2.5.4.SP3 > Reporter: Kyle Lape > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.2.4.SP1, 2.5.4.SP4 > > > Running the following code is an alternative way to set the keystore/truststore in a remoting client: > {noformat} > KeyStore ksTrust = KeyStore.getInstance("JKS"); > ksTrust.load(new FileInputStream("testTrust"), passphrase); > TrustManagerFactory tmf = > TrustManagerFactory.getInstance("SunX509"); > tmf.init(ksTrust); > SSLContext sslContext = SSLContext.getInstance("TLS"); > sslContext.init(null, tmf.getTrustManagers(), null); > HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory()); > {noformat} > When this code is added, Remoting should not try to create its own {{SSLSocketFactory}}. Currently there is no way to tell Remoting to not try. This causes a confusing ERROR message: > {noformat} > Error creating SSL Socket Factory for client invoker: Error initializing socket factory SSL context: Can not find truststore url. > {noformat} > After this message is logged, the client still works because it falls back to the default {{SSLSocketFactory}} (that was already set). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1306) Remoting tries to create SSLSocketFactory even when not desired

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1306?page=com.atlassian.jira.plugin... ] Ron Sigal commented on JBREM-1306: ---------------------------------- There is a new configuration parameter: org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.USE_DEFAULT_SSL_SOCKET_FACTORY (actual value "useDefaultSslSocketFactory"). If it is set to true, then HTTPSClientInvoker.createSocketFactory() will call HttpsURLConnection.getDefaultSSLSocketFactory() instead of trying to build a SocketFactory. Unit test: org.jboss.test.remoting.transport.http.ssl.socketfactory.DefaultSocketFactoryTestCase. Waiting for results in jenkins. > Remoting tries to create SSLSocketFactory even when not desired > --------------------------------------------------------------- > > Key: JBREM-1306 > URL: https://issues.jboss.org/browse/JBREM-1306 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.4, 2.5.4.SP3 > Reporter: Kyle Lape > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.2.4.SP1, 2.5.4.SP4 > > > Running the following code is an alternative way to set the keystore/truststore in a remoting client: > {noformat} > KeyStore ksTrust = KeyStore.getInstance("JKS"); > ksTrust.load(new FileInputStream("testTrust"), passphrase); > TrustManagerFactory tmf = > TrustManagerFactory.getInstance("SunX509"); > tmf.init(ksTrust); > SSLContext sslContext = SSLContext.getInstance("TLS"); > sslContext.init(null, tmf.getTrustManagers(), null); > HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory()); > {noformat} > When this code is added, Remoting should not try to create its own {{SSLSocketFactory}}. Currently there is no way to tell Remoting to not try. This causes a confusing ERROR message: > {noformat} > Error creating SSL Socket Factory for client invoker: Error initializing socket factory SSL context: Can not find truststore url. > {noformat} > After this message is logged, the client still works because it falls back to the default {{SSLSocketFactory}} (that was already set). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks

by Doug Grove (JIRA)

Doug Grove created JBREM-1307: --------------------------------- Summary: TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks Key: JBREM-1307 URL: https://issues.jboss.org/browse/JBREM-1307 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.3.SP2 Environment: JBoss EAP 4.3.0 CP08 and CP10 Reporter: Doug Grove In order to provide a mechanism for timing out a network/socket write operation, the org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the duration of the write operation exceeds the timer interval, then the timer will call close() on the output stream. This interrupts the output stream write() operation and causes the write operation to throw an IOException. When the output stream uses secure sockets (SSL), however, the call to close() on the output stream can block indefinitely. The threads associated with the write() and close() operation will only clear when the tcp keepalive timeout mechanism in the operation system is invoked. This appears to be related to a know bug in the java runtime: http://bugs.sun.com/view_bug.do?bug_id=6358629 Specifically, in a thread dump you will see: "Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition [0x4cbad000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x585021a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362) - locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301) at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80) at org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57) at org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

4
4
0 / 0

[JBoss JIRA] (JBREM-1302) Can't invoke remote object if server bind address is 0.0.0.0

by Sergey Chernov (Created) (JIRA)

Can't invoke remote object if server bind address is 0.0.0.0 ------------------------------------------------------------ Key: JBREM-1302 URL: https://issues.jboss.org/browse/JBREM-1302 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.5.4.SP2 Environment: Jboss 5.1.0 jdk 1.6 jboss remoting 2.5.4.SP2 Reporter: Sergey Chernov When jboss bind address is set to `0.0.0.0` remote client gets exception while trying to invoke remote object's method: java.rmi.ConnectException: Connection refused to host: lx4-schernov.nn.five9.com; nested exception is: java.net.ConnectException: Connection refused: connect at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601) at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110) at org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub.transport(Unknown Source) at org.jboss.remoting.transport.rmi.RMIClientInvoker.callTransport(RMIClientInvoker.java:648) at org.jboss.remoting.transport.rmi.RMIClientInvoker.access$100(RMIClientInvoker.java:78) at org.jboss.remoting.transport.rmi.RMIClientInvoker$1.run(RMIClientInvoker.java:402) at org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:147) at org.jboss.util.threadpool.BasicThreadPool.executeOnThread(BasicThreadPool.java:473) at org.jboss.util.threadpool.BasicThreadPool.runTaskWrapper(BasicThreadPool.java:201) at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:420) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:169) at org.jboss.remoting.Client.invoke(Client.java:2070) at org.jboss.remoting.Client.invoke(Client.java:879) at org.jboss.remoting.Client.invoke(Client.java:867) at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:479) at $Proxy0.getMySumHost(Unknown Source) at test.Main.main(Main.java:45) Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:193) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:525) at java.net.Socket.connect(Socket.java:475) at java.net.Socket.<init>(Socket.java:372) at java.net.Socket.<init>(Socket.java:186) at javax.net.DefaultSocketFactory.createSocket(SocketFactory.java:206) at org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory.createSocketPrivate(RemotingRMIClientSocketFactory.java:333) at org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory.createSocket(RemotingRMIClientSocketFactory.java:210) at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595) ... 18 more It happens because RemotingRMIClientSocketFactory had been created with wrong ('0.0.0.0') host name which becomes effective host while creating socket: log: 328 [main] TRACE org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory - host: lx4-schernov.nn.five9.com, effective host: 0.0.0.0, port: 47952 source: public Socket createSocket(String host, final int port) throws IOException 176 { ... 181 final String effectiveHost = hostName != null ? hostName : host; While creating factory it should be checked, that host name is not broadcast or localhost address, to make client's locatorUri mandatory for such cases. Client source code: String address = "remote.host.com"; Properties props = new Properties(); props.put(InitialContext.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); props.put(InitialContext.PROVIDER_URL, "jnp://" + address + ":1099"); props.put(InitialContext.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); InitialContext context = new InitialContext(props); Object tmp = context.lookup("remote/subsystem/Object"); ObjectInf object = (ObjectInf) tmp; object.doJob(); // here exception it thrown -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

5
5
0 / 0

← Newer
1
2
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues July 2012