I do think we need to have a look at it (and I may find some time to do
it too, as I'm in vacation in the coming week)
However, I think we should get this 2.0 out. Ther eis no problem in
releasing a fix if needed.
Thanks !
On 09/07/2022 07:17, Jonathan Valliere wrote:
Sooo… do I need to look into this or was this resolved?
On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny <[email protected]
<mailto:[email protected]>> wrote:
The changes I did were to ensure that any ouutbound data are sent
when a
TLS erroroccurs, because the Alert must be sent no matter what. This is
critical for a client to know what is the cause of the failure
(typically when a bad certificate is provided - expired, revoked,
etc -):
https://datatracker.ietf.org/doc/html/rfc5246#section-7.2
<https://datatracker.ietf.org/doc/html/rfc5246#section-7.2>
I also checked that in this case an exception is propagated up to the
IoHandler for teh server to be informed about the situuation.
On 06/07/2022 12:42, Jonathan Valliere wrote:
> What test are you trying? Emmanuel made changes from the
original design
> to cause it to throw on the filter. My original design threw on
the filter
> but only during a subsequent read or write action thereby
enforcing strong
> concurrency within the pipeline.
>
> On Jul 6, 2022 at 3:53:57 AM, Christoph John
> <[email protected]
<mailto:[email protected]>.invalid> wrote:
>
>> Ok, the tests in QuickFIX/J which expect the exception to be
caught in a
>> filter still don't work.
>> I recall that you also did some changes in other Apache projects
to make
>> it work with MINA 2.2.0. Could it be that I also need to adapt
something in
>> this regard?
>>
>> Thanks
>> Chris
>>
>> Jul 5, 2022 18:47:09 Emmanuel Lécharny <[email protected]
<mailto:[email protected]>>:
>>
>> I have tested that the exception gets propagated before
launching the vote
>> to be clear :-)
>>
>>
>> On 05/07/2022 18:17, Christoph John wrote:
>>
>>> Sorry, no. The last message regarding this was:
>>
>>>
>>
>>> ----------snip---------
>>
>>>
>>
>>> 11.04.2022 09:37:30 Emmanuel Lécharny <[email protected]
<mailto:[email protected]>>:
>>
>>> Hi Christophe,
>>
>>> sorry, my late mail was off base.
>>
>>> The pb here is that the SSLEngine excpeiton is not propagated
to the
>> handler, when it should.
>>
>>> My guess is that we have some missing call somewhere in the
stack. I'm
>> going to check that out.
>>
>>> On 11/04/2022 00:15, Christoph John wrote:
>>
>>>> Hi,
>>
>>>> thanks Jonathan and Emmanuel for working on this!
>>
>>>> I tried to integrate this into QuickFIX/J and it compiles
successfully.
>> However there are some tests failing that expect an Exception.
For example
>> we have
>>
>>>>
>>
https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54
<https://github.com/quickfix-j/quickfixj/blob/b6a822a46a5278dcd0985a5a77299ed03168ab03/quickfixj-core/src/test/java/quickfix/mina/ssl/SecureSocketTest.java#L54>
>>
>>>> Up to now it was tried to get the Exception via a filter in
the chain.
>> This no longer seems to work but I think I can see the error
getting thrown
>> in the log:
>>
>>>> SEVERE: SSLHandlerG0@590ec99c[mode=server, connected=false]
task() -
>> storing error {}
>>
>>>> javax.net.ssl.SSLHandshakeException: No available
authentication scheme
>>
>>>> at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
>>
>>>> at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>
>>>> at
>>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:358)
>>
>>>> at
>>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
>>
>>>> at
>>
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:305)
>>
>>>> at
>>
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:972)
>>
>>>> at
>>
java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:961)
>>
>>>> at
>>
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
>>
>>>> at
>>
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1246)
>>
>>>> at
>>
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1182)
>>
>>>> at
>>
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:840)
>>
>>>> at
>>
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:801)
>>
>>>> at
>>
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
>>
>>>> at
>>
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
>>
>>>> at
>>
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1277)
>>
>>>> at
>>
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1264)
>>
>>>> at
>>
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>>
>>>> at
>>
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1209)
>>
>>>> at
>>
org.apache.mina.filter.ssl.SSLHandlerG0.execute_task(SSLHandlerG0.java:743)
>>
>>>> at
>>
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:255)
>>
>>>> at
>>
org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
>>
>>>> at
>>
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
>>
>>>> at
>>
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>>
>>>> at
>>
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
>>
>>>> at
>>
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
>>
>>>> at
>>
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
>>
>>>> at
>>
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
>>
>>>> at
>>
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643)
>>
>>>> at
>>
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
>>
>>>> at
>>
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
>>
>>>> at
>>
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224)
>>
>>>> at
>>
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
>>
>>>> at
>>
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
>>
>>>> at
>>
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
>>
>>>> at
>>
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>>
>>>> at
>>
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>>
>>>> at java.base/java.lang.Thread.run(Thread.java:833)
>>
>>>> What is the new way to get this Exception?
>>
>>>> NB: I recall discussing this with Jonathan some months ago but
seem to
>> have lost track of the mail thread.
>>
>>>> Thanks in advance,
>>
>>>> Chris.
>>
>>>> On 09.04.22 00:26, Emmanuel Lécharny wrote:
>>
>>>>> Hi !
>>
>>>>>
>>
>>>>> I will start to cut a first milestone for the MINA
<https://www.google.com/maps/search/rt+to+cut+a+first+milestone+for+the+MINA?entry=gmail&source=g>
2.2.X branch. It
>> has been tested on Apache Ftpserver, Ldap API and Directory
Server with
>> success.
>>
>>>>>
>>
>>>>> There will probably be more milestone, but that would be a
first step.
>>
>>>>>
>>
>>>>> The main changes are:
>>
>>>>> - a complete redesign of the TLS handling
>>
>>>>> - the removal of the SslFilter.DISABLE_ENCRYPTION_ONCE attribute,
>> which is either replaced by a dedicated filter, or the
encapsulation of the
>> message in a DisableEncryptWriteRequest interface
>>
>>>>>
>>
>>>>>
>>
>>>>> I'll do that this week-end.
>>
>>>>>
>>
>>>>> Thanks !
>>
>>>>
>>
>>>
>>
>>
>> --
>>
>> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
>>
>> T. +33 (0)4 89 97 36 50
>>
>> P. +33 (0)6 08 33 32 61
>>
>> [email protected] <mailto:[email protected]>
https://www.busit.com/ <https://www.busit.com/>
>>
>>
>>
---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
>>
>> For additional commands, e-mail: [email protected]
<mailto:[email protected]>
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
>> For additional commands, e-mail: [email protected]
<mailto:[email protected]>
>>
>>
>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
[email protected] <mailto:[email protected]>
https://www.busit.com/ <https://www.busit.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
[email protected] https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
