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/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
