[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-971) Enhance server-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded

[Ovidiu Feodorov (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-971?page=comments#action_12411726 ] 
            
Ovidiu Feodorov commented on JBREM-971:
---------------------------------------

Please find the patch attached (JBREM-971.patch).

It was written against the 2.x branch (r4122). Please port to other branches as appropriate.

It consists of removing the try/finally block around the stream creation statements in org.jboss.remoting.transport.socket.ClientSocketWrapper.java. To me, it does make sense to insist in resetting the timeout if stream creation fails: if that happens, the timeout will be the least of server's problems, and the original exception will be swallowed and replaced with a side-effect exception. The original exception should be allowed to bubble up instead, making clear the root cause of the failure.

Here's the exception that shows up in logs before the fix:

Caused by: java.net.SocketException: Socket Closed
        at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:201)
        at java.net.Socket.setSoTimeout(Socket.java:997)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:2047)

Here's the exception that shows up in logs after the fix:

Caused by: javax.net.ssl.SSLException: Received fatal alert: internal_error
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1657)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
        at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)

Correlated with the clearer exception logged on the client side (see JBREM-970), it makes a lot clearer that the problem is due to misconfiguration of the SSL socket layer.

I have not run a full testsuite, please do so and validate the patch.

> Enhance server-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-971
>                 URL: http://jira.jboss.com/jira/browse/JBREM-971
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4.0.CR2
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 2.4.0.GA
>
>         Attachments: JBREM-971.patch
>
>
> A SSL connection (for example) may fail due to handshake problems, but Remoting would discard the original exception and throw a different and less relevant exception, thus hiding the original cause of the error.
> Example:
> The server reports 
> Caused by: java.net.SocketException: Socket Closed
>         at java.net.PlainSocketImpl.setOption(Unknown Source)
>         at java.net.Socket.setSoTimeout(Unknown Source)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(Unknown Source)
>         at org.jboss.remoting.transport.socket.SocketWrapper.setTimeout(SocketWrapper.java:85)
>         at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:168)
>         at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
> while in fact the root problem is:
> 14:39:38,174 ERROR [STDERR] javax.net.ssl.SSLException: Received fatal alert: internal_error
> 14:39:38,175 ERROR [STDERR]     at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
> 14:39:38,175 ERROR [STDERR]     at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
> 14:39:38,175 ERROR [STDERR]     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1657)
> 14:39:38,175 ERROR [STDERR]     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932)
> 14:39:38,175 ERROR [STDERR]     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
> 14:39:38,175 ERROR [STDERR]     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
> 14:39:38,175 ERROR [STDERR]     at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
> 14:39:38,175 ERROR [STDERR]     at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
> This makes troubleshooting of a potential simple problem such a misspelled truststore file name laborious and time consuming.
> The server-side code could be modified to log relevant exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira