Jonathan,

I don't think it worth it to keep going the investigation in Java 8.

First because it works with Java 11
Second because reneg is not available in TLS V3

I would simply disable this test, or check the Java version when running the test, somtehing like:

    public void testMessageSentIsCalled_With_SSL() throws Exception {
        String javaVersion = System.getProperty("java.runtime.version");

        if (!javaVersion.startsWith("1.8")) {
            testMessageSentIsCalled(true);
        }
    }


On 15/01/2022 15:09, Jonathan Valliere wrote:
Emmanuel,

Disabling the handshake aggregation by setting ENABLE_FAST_HANDSHAKE to
false still has it fail on Java 8.

This could be a straight up bug in Java 8 with renegotiations.  I also
tried disabling the CLOSE messages, but it didn't make any difference.



On Sat, Jan 15, 2022 at 1:05 AM Emmanuel Lécharny <[email protected]>
wrote:


Hi Jona than,

indeed, same here. If I switch to Java 11, it passes.

What puzzles me is that the same test passes with Java 8 on MINA 2.1.5...

Now, let's face reality: in TLS 1.3, reneg has been deprecated, so this
test is soon going to be useless. And Java 8 is not anymore maintained
(unless you pay for it), so I don't really mind if we decide that Java
11 is mandatory for MINA 2.2.

I suspect there is some issue in the way Java 8 process incoming data.
In MINA 2.2, the read buffer contains all the HS server data
(ServerHello + ChangeCipherSpec +ServerHandshakeFinished) in one PDU,
while in MINA 2.1.5 the client has to read 3 PDUs to get the same data.
This may make a difference.


Thanks !


On 15/01/2022 04:17, Jonathan Valliere wrote:
Additionally, that unit test you referenced is passing for me on
AdoptOpenJDK 11

On Fri, Jan 14, 2022 at 10:10 PM Jonathan Valliere <[email protected]
<mailto:[email protected]>> wrote:

     Can you send the server debugging logs?

     On Fri, Jan 14, 2022 at 7:46 PM Emmanuel Lécharny
     <[email protected] <mailto:[email protected]>> wrote:



         On 14/01/2022 18:48, Emmanuel Lécharny wrote:
          > Hi Jonathan,
          >
          > I also have a failure in
         SslFilterTest.testMessageSentIsCalled_With_SSL.
          >
          > What happens is that we try to send 2 messages (test-1 and
         test-2) with
          > SSL established, but we do a SSL renegociation in between the
         first
          > message sending and the second.
          >
          > For some unknown reason, when we try to read the response on
         the client
          > side (something we do in one shot after the second message
         has been
          > sent), we never get back the second message.
          >
          > I'm positive it has been sent, I strongly suspect that the
         client socket
          > lose it during the SSL uncrypting *after* the Ssl reneg has
         occured.

         So here are the data being sent by the server with MINA 2.1.5:

         HeapBuffer[pos=0 lim=1332 cap=2115: 16 03 03 05 2F 02 00 00 51
         03 03 61
         E2 12 0B 67] (ServerHello)
         HeapBuffer[pos=0 lim=6 cap=8: 14 03 03 00 01 01]
(ChangeCipherSpec)
         HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 43 27 00 F6 69
         CD 46 99
         0D A4 B2] (ServerHandshakeFinished)
         HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 6E 02 38 7C 72
         31 73 EF
         12 00 F6] (Data)

         rehandhsake

         HeapBuffer[pos=0 lim=181 cap=264: 16 03 03 00 B0 7D 9A 82 9D 00
         34 46 FB
         53 6C 16] (ServerHello)
         HeapBuffer[pos=0 lim=85 cap=132: 14 03 03 00 50 99 F3 FC 9C 7E
         FF 9A 7C
         5C BA C7] (ChangeCipherSpec)
         HeapBuffer[pos=0 lim=101 cap=132: 16 03 03 00 60 80 B1 2C C0 6F
         B8 5A 5C
         2D 46 26] (ServerHandshakeFinished)
         HeapBuffer[pos=0 lim=85 cap=132: 17 03 03 00 50 0C D5 D8 0E CB
         18 F1 A4
         AA 75 27]
         HeapBuffer[pos=0 lim=85 cap=132: 15 03 03 00 50 42 7B BE AF B8
         2C 64 88
         F3 F5 A6]


         And with MLINA 2.2.0:

         HeapBuffer@4b38503[pos=0 lim=1332 cap=33842: 16 03 03 05 2F 02
         00 00 51
         03 03 61 E2 13 CE CD] (ServerHello)
         HeapBuffer@58e57fe3[pos=0 lim=107 cap=33842: 14 03 03 00 01 01
         16 03 03
         00 60 AA 0C 98 25 E0] (ChangeCipherSpec) +
(ServerHandshakeFinished)
         HeapBuffer@26e25a06[pos=0 lim=85 cap=33842: 17 03 03 00 50 F9 A1
         D5 CB
         5E 78 73 29 60 C0 FF] (Data)

         rehandshake

         HeapBuffer@1558ae1[pos=0 lim=367 cap=33842: 16 03 03 00 B0 BF CD
         B1 5D
         F9 5B FC 56 11 52 69] (ServerHello) + ChangeCipherSpec) +
         (ServerHandshakeFinished)
         HeapBuffer@5038afc9[pos=0 lim=85 cap=33842: 17 03 03 00 50 6A F9
         B7 57
         5C A3 1D A0 14 26 87] (Data)


         It's pretty much like if the server sends HS data as a whole
         instead of
         splitting them in pieces. However, I think everything is there,
         so I
         don't understand why it fails in MINA 2.2...

         --
         *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/



--
*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]

Reply via email to