You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2016/12/29 11:56:58 UTC
[jira] [Commented] (QPID-6991) NonBlockingConnection does not
always gracefully close TLS connections
[ https://issues.apache.org/jira/browse/QPID-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15785184#comment-15785184 ]
Keith Wall commented on QPID-6991:
----------------------------------
With the current behaviour of the Qpid JMS Client, the problem does not manifest. Providing the AMQP close is immediately followed by the TLS close_notify bytes, the existing NonBlockingConnection#doWork processes both and no warning will be seen. If the closes arrive in separate read, the problem will still occur.
As the problem does not occur for the Qpid JMS Client, reducing the priority of this issue to Minor.
> NonBlockingConnection does not always gracefully close TLS connections
> ----------------------------------------------------------------------
>
> Key: QPID-6991
> URL: https://issues.apache.org/jira/browse/QPID-6991
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: qpid-java-6.0
> Reporter: Keith Wall
> Priority: Minor
> Fix For: Future
>
>
> As exposed by QPID-6975, NonBlockingConnection's handling of TLS connection close is deficient.
> Currently for AMQP 0-8..0-10, the receipt of the AMQP connection close from the client causes the NBC#_closed to be marked true (NonBlockingConnection#close is called from the protocol layer) and the NonBlockingConnectionDelegate and SocketChannel are shutdown immediately (as that invocation of #doWork finishes). This means that the Broker never reads the SSL close_notify that ought to be sent by the client, so the following warning is logged:
> {noformat}
> 2016-01-09 17:01:01,055 DEBUG [IO-/127.0.0.1:51231] o.a.q.s.t.NonBlockingConnectionTLSDelegate Exception when closing SSLEngine
> javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_45]
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_45]
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_45]
> at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1561) ~[na:1.8.0_45]
> at org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.shutdownOutput(NonBlockingConnectionTLSDelegate.java:364) ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at org.apache.qpid.server.transport.NonBlockingConnection.shutdownOutput(NonBlockingConnection.java:409) [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:360) [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:299) [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:108) [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:502) [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:340) [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:86) [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:460) [qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> For AMQP 1.0, things are a little better. The protocol layer does not currently immediately close the connection and so the connection is left open and the the SSL close_notify will be read.
> The process on connection close for TLS connections on non Windows platform needs to be something like:
> # write AMQP close-ok
> # install ConnectionCloseTicker
> # close SSLEngine outbound
> # write again (to send the close_notify bytes)
> # socket channel shutdown outbound
> # socket channel should remain registered for OP_READ until -1 is encountered, or CCT ticker is timed-out,
> # close SSLEngine inbound
> # socket channel shutdown inbound
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org