[
https://issues.apache.org/jira/browse/QPID-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199431#comment-16199431
]
Keith Wall edited comment on QPID-7967 at 10/10/17 9:57 PM:
------------------------------------------------------------
The classes I highlight above are those relating to the server side's support
for SSL session resumption.
* When connecting the Qpid JMS Client AMQP 0-x, the objects don't accumulate
because the client fails to close the TLS connection cleanly [1]. The abnormal
close disallows the SSL session resumption so the server won't preserve them
needlessly [2].
* When connecting the Qpid JMS Client, it does close the TLS connection
cleanly, so the server side preserves caches the objects. However, as the Qpid
JMS Client doesn't (by default) reuse its {{SSLContext}}, the client does not
take advantage of this. This is why I see the number of cached sessions on the
server grows. Side note: I notice I can workaround by passing an SSLContext
into the client (is there a better way??):
{code}
ConnectionFactory factory = (ConnectionFactory)
context.lookup("myFactoryLookup");
((JmsConnectionFactory)
factory).setSslContext(TransportSupport.createSslContext(new
TransportSslOptions()));
{code}
With this I see the shortened SSL handshake/session reuse is evident from the
client with {{-Djavax.net.debug=ssl}} enabled:
{noformat}
..%% Client cached [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
%% Try resuming [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256] from port -1
*** ClientHello, TLSv1.2
...
{noformat}
I don't think there is a Java Broker defect here, but inspired by the
conversation on https://github.com/netty/netty/issues/832, I think there is a
case for allow the Broker's
javax.net.ssl.SSLContext#ServerSessionContext#sessionTimeout and
#sesionCacheSize to be tuned (from context variables) to allow users to work
around overly large pools of unused SSL sessions.
[1] https://issues.apache.org/jira/browse/QPID-6981
[2] RFC 2246 section 7.2 "Alert protocol" https://www.ietf.org/rfc/rfc2246.txt
was (Author: k-wall):
The classes I highlight above are those relating to the server side's support
for SSL session resumption.
* When connecting the Qpid JMS Client AMQP 0-x, the objects don't accumulate
because the client fails to close the TLS connection cleanly [1]. The abnormal
close disallows the SSL session resumption so the server won't preserve them
needlessly [2].
* When connecting the Qpid JMS Client, it does close the TLS connection
cleanly, so the server side preserves caches the objects. However, as the Qpid
JMS Client doesn't (by default) reuse its {{SSLContext}}, the client does not
take advantage of this. This is why I see the number of cached sessions on the
server grows. Side note: I notice I can workaround by passing an SSLContext
into the client (is there a better way??):
{code}
ConnectionFactory factory = (ConnectionFactory)
context.lookup("myFactoryLookup");
((JmsConnectionFactory)
factory).setSslContext(TransportSupport.createSslContext(new
TransportSslOptions()));
{code}
With this I see the shortened SSL handshake/session reuse is evident from the
client with {{-Djavax.net.debug=ssl}} enabled:
{noformat}
..%% Client cached [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
%% Try resuming [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256] from port -1
*** ClientHello, TLSv1.2
...
{noformat}
I don't think there is a Java Broker defect here, but inspired by the
conversation on https://github.com/netty/netty/issues/832, I think there is a
case for allow the Broker's
javax.net.ssl.SSLContext#ServerSessionContext#sessionTimeout and
#sesionCacheSize to be tuned (from context variables) to allow users to work
around overly large pools of unused SSL sessions.
[1]https://issues.apache.org/jira/browse/QPID-6981
[2] RFC 2246 section 7.2 "Alert protocol" https://www.ietf.org/rfc/rfc2246.txt
> [Java Broker] Internal Oracle TLS classes leaked per connection when
> connecting the AMQP 1.0 Qpid JMS Client
> ------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7967
> URL: https://issues.apache.org/jira/browse/QPID-7967
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Environment: Java version "1.8.0_144"
> Mac OS X 10.12.6
> Reporter: Keith Wall
>
> Performing leak analysis shows that the following internal TLS classes are
> leaked, once per TLS connection, when connecting using the Qpid JMS Client
> 0.26.0 over AMQP 1.0 with TLS. The same leak was not apparent when connecting
> the older Qpid JMS AMQP 0-x client.
> The classes are:
> # sun.security.ssl.SessionId
> # sun.security.ssl.SSLSessionImpl
> The test is run with the following command:
> {code}
> mvn exec:java -pl tools -Dstresstest=qpid-jms-client
> -Dexec.args="jndiProperties=stress-test-client-qpid-jms-client.properties
> jndiConnectionFactory=qpidConnectionFactoryTls connections=100"
> -Djavax.net.ssl.trustStore=/Users/keith/Downloads/myks.jks
> -Dqpid-jms-client-version=0.26.0
> {code}
> It seems there is session caching going on within the JDK. The cache size
> and timeout looks to be tuneable with
> {{javax.net.ssl.SSLContext#getServerSessionContext}}. The default timeout is
> 86400s (1day) and a session cache size of 0 (unbounded). I suspect if Broker
> had a sufficiently large number of TLS connections over a short time period,
> memory may be exhausted.
> -I don't currently understand why the behaviour is different between the
> old/new JMS client-. Edit - see comment below.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
