Have you tried printing the entirety of the contents from the Socket inbound and compare against what is passed into the SSLEngine to make sure our buffer combination/management isn’t corrupting the stream?
On Jan 28, 2022 at 7:45:29 PM, Emmanuel Lécharny <[email protected]> wrote: > Ok, moving forward: > > The test does: > > - create the server and set the SSLFilter with TLS 1.2 > - create the secured connection (TLSv1.2) > - write a first message ('test-1') > - that initiate the HS, then the message is written to the server > - once the HS is completed, the response is sent (response 1) > - the SSLSocket session is invalidated on the client side > - we do a startHandshake on the client > - the server receives the HS message and send back the HS response > *** The client never processes the incoming HS message*** > - the client sends the second message > - the server receives the message and write back the response > - the server closes the connection > > > I have no idea why the client does not prcoess the second HS message > received from the server... > > On 29/01/2022 00:29, Emmanuel Lécharny wrote: > > It should. > > > What is really puzzling is when we set the server to use TLS 1.2 *and* > > the client to TLS 1.2, and that fails whatever Java version we use... > > > On 29/01/2022 00:14, Jonathan Valliere wrote: > > > Shouldn’t it be downgrading during the handshake? > > > > > > On Fri, Jan 28, 2022 at 6:12 PM Emmanuel Lécharny <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > Hi Jonathan, > > > > > > after a big fight, I finally found that the SslFilterTest was > > > failing in > > > Mina 2.2 with Java 8 and 11 when the client was not set to use TLS > > > V1.3 > > > (it was set to use "TLS"). Note that the client is a plain SSL > > > Socket, > > > created by a SSLSocketFactory. > > > > > > So the combinations that work : > > > Java 8 + Client TLSv1.3 + Server TLSv1.2 -> OK > > > Java 11 + Client TLSv1.3 + Server TLSv1.2 -> OK > > > Java 8 + Client TLSv1.3 + Server TLSv1.3 -> OK > > > Java 11 + Client TLSv1.3 + Server TLSv1.3 -> OK > > > > > > And for those that don't work: > > > Java 8 + Client TLSv1.2 + Server TLSv1.2 -> KO > > > Java 11 + Client TLSv1.2 + Server TLSv1.2 -> KO > > > Java 8 + Client TLSv1.2 + Server TLSv1.3 -> KO > > > Java 11 + Client TLSv1.2 + Server TLSv1.3 -> KO > > > > > > That is a bit problematic as we may have client that aren't using > > > TLS 1.3... > > > > > > On 21/01/2022 16:23, Emmanuel Lécharny wrote: > > > > > > > > > > > > On 21/01/2022 13:23, Jonathan Valliere wrote: > > > >> You can also use the DisableEncryptionWriteRequesf to wrap your > > > >> WriteRequest you want to bypass the SSL filter. > > > > > > > > Yes, but all in all, I think this WriteRequest class should go. > > > The > > > > original Attribute was specifically created to bypass the > > > SslFilter for > > > > the StartTLS operation, and in retrospect, thatw as a mistake. > > > > > > > > I like the Filter idea. > > > > > > > > > > -- *Emmanuel Lécharny - CTO* 205 Promenade > > > > > > < > https://www.google.com/maps/search/Emmanuel+L%C3%A9charny+-+CTO*+205+Promenade+?entry=gmail&source=g>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/ >
