[ 
https://issues.apache.org/jira/browse/QPID-8587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625146#comment-17625146
 ] 

Tomas Vavricka commented on QPID-8587:
--------------------------------------

The commit message contains a different Jira ID.

The actual commit implementing this JIRA is 
[802ddfa|https://github.com/apache/qpid-broker-j/commit/802ddfa14d5e88781bf52a6528368ea35178d166].

> [Broker-J] SNI hostname handling for java 11/17 compatibility
> -------------------------------------------------------------
>
>                 Key: QPID-8587
>                 URL: https://issues.apache.org/jira/browse/QPID-8587
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Broker-J
>    Affects Versions: qpid-java-broker-8.0.6
>            Reporter: Daniil Kirilyuk
>            Priority: Minor
>
> When building Broker-J under Java 17 there is an error thrown in unit test:
> {code:java}
> INFO] Running org.apache.qpid.server.transport.SNITestINFO] Running 
> org.apache.qpid.server.transport.SNITest[ERROR] Tests run: 6, Failures: 0, 
> Errors: 1, Skipped: 0, Time elapsed: 8.963 s <<< FAILURE! - in 
> org.apache.qpid.server.transport.SNITest[ERROR] 
> testBypassInvalidSniHostname(org.apache.qpid.server.transport.SNITest)  Time 
> elapsed: 1.547 s  <<< ERROR!javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated at 
> org.apache.qpid.server.transport.SNITest.performTest(SNITest.java:219) at 
> org.apache.qpid.server.transport.SNITest.testBypassInvalidSniHostname(SNITest.java:172){code}
> The issue here seems to be more strict SNI hostname validation in Java 17 
> comparing to Java 11. 
> Stacktrace:
> {code:java}
> java.base/sun.security.ssl.ServerNameExtension$CHServerNamesSpec.<init>(ServerNameExtension.java:138)
> java.base/sun.security.ssl.ServerNameExtension$CHServerNameConsumer.consume(ServerNameExtension.java:299)
> java.base/sun.security.ssl.SSLExtension.consumeOnLoad(SSLExtension.java:609)
> java.base/sun.security.ssl.SSLExtensions.consumeOnLoad(SSLExtensions.java:201)
> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1176)
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.runSSLEngineTasks(NonBlockingConnectionTLSDelegate.java:365)
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:144)
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:545)
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:345)
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:95)
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:503)
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$createQpidByteBufferTrackingThreadFactory$0(QpidByteBufferFactory.java:464)
> java.base/java.lang.Thread.run(Thread.java:833){code}
> SSLUtil#createSNIHostName now throws an exception even when passing a byte 
> array instead of a string argument. This behavior change probably couldn't be 
> avoided. As in unit test is used hostname "_foo" with the invalid underscore 
> character, it will fail. 
> In Broker-J there is a possibility to ignore invalid SNI hostname provided by 
> client introduced by QPID-8535. This is achieved by setting AMQP port context 
> variable "qpid.port.amqp.ignoreInvalidSni" to true (default value false). 
> When doing so client could provide an invalid SNI hostname (see [Qpid JMS 
> client 
> configuration|https://qpid.apache.org/releases/qpid-jms-0.51.0/docs/index.html#connection-uri])
>  and still be able to establish connection to the broker. This flag seem to 
> have no effect since java 17, because the exception is thrown by sslEngine 
> when performing the handshake.
> I would suggest marking flag "qpid.port.amqp.ignoreInvalidSni" as deprecated 
> as its value will make no difference in future java versions since 17 and 
> delete it and associated logic in one of the future broker major releases. 
> Failing unit test SNITest#testBypassInvalidSniHostname() can be fixed by 
> adding assume condition checking the java version.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to