----- Mail original ----- > De: "Matt Caswell" <matt@xxxxxxxxxxx> > À: "openssl-users" <openssl-users@xxxxxxxxxxx> > Envoyé: Mardi 16 Janvier 2018 16:58:11 > Objet: Re: Multiple reconnection in OpenSSL 1.1.0 > On 16/01/18 15:27, Huy Cong Vu wrote: >> Here is any traffic transfer between my clients and server from the beginning to >> the 1st failed SSL_read(): >> https://pastebin.com/raw/Bjixearh >> >> IP src: 192.168.1.4 >> IP dest: 192.168.1.121 >> >> I'm not sure the version I pasted have enough informations, if you want more, >> please show me how to do it in Wireshark. > > It's difficult to read in that form - but enough I think. > > Most of this trace shows a "normal" connection and transfer of > application data. The client (192.168.1.4:63862) connects to the server > (192.168.1.121:8042) and sends its ClientHello. There then follows a > client-auth handshake (both sides exchange Certificates) and TLSv1.2 is > negotiated. The client and server then exchange a number of encrypted > application data records. > > After a while we see the first connection being torn down: > > No. Time Source Destination > Protocol Length Info > 796 61.056981 192.168.1.121 192.168.1.4 TCP > 60 8042 → 63862 [FIN, ACK] Seq=4619 Ack=3969 Win=39936 Len=0 > > Frame 796: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on > interface 0 > Ethernet II, Src: PcsCompu_44:b5:3d (08:00:27:44:b5:3d), Dst: > Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Destination: Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Source: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Type: IPv4 (0x0800) > Padding: 000000000000 > Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.4 > Transmission Control Protocol, Src Port: 8042, Dst Port: 63862, Seq: > 4619, Ack: 3969, Len: 0 > > No. Time Source Destination > Protocol Length Info > 797 61.057009 192.168.1.4 192.168.1.121 TCP > 54 63862 → 8042 [RST, ACK] Seq=3969 Ack=4619 Win=0 Len=0 > > Frame 797: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on > interface 0 > Ethernet II, Src: Micro-St_57:60:85 (d4:3d:7e:57:60:85), Dst: > PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Destination: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Source: Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Type: IPv4 (0x0800) > Internet Protocol Version 4, Src: 192.168.1.4, Dst: 192.168.1.121 > Transmission Control Protocol, Src Port: 63862, Dst Port: 8042, Seq: > 3969, Ack: 4619, Len: 0 > > > Next we see a new TLS connection being established and an unencrypted > ClientHello coming in (from a different port - 63868): > > Frame 1107: 172 bytes on wire (1376 bits), 172 bytes captured (1376 > bits) on interface 0 > Ethernet II, Src: Micro-St_57:60:85 (d4:3d:7e:57:60:85), Dst: > PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Destination: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Source: Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Type: IPv4 (0x0800) > Internet Protocol Version 4, Src: 192.168.1.4, Dst: 192.168.1.121 > Transmission Control Protocol, Src Port: 63868, Dst Port: 8042, Seq: 1, > Ack: 1, Len: 118 > Data (118 bytes) > > 0000 16 03 01 00 71 01 00 00 6d 03 03 c0 57 4d fc 23 ....q...m...WM.# > 0010 5b 02 67 2c 02 ae 59 f1 40 e8 29 5d 29 aa c8 bf [.g,..Y.@.)])... > 0020 41 4b 14 a2 26 08 e7 c1 91 40 c2 00 00 04 c0 14 AK..&....@...... > 0030 00 ff 01 00 00 40 00 0b 00 04 03 00 01 02 00 0a .....@.......... > 0040 00 04 00 02 00 17 00 23 00 00 00 16 00 00 00 17 .......#........ > 0050 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05 01 ..... .......... > 0060 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 ................ > 0070 02 01 02 02 02 03 > > > But the server responds with this: > > Frame 1109: 111 bytes on wire (888 bits), 111 bytes captured (888 bits) > on interface 0 > Ethernet II, Src: PcsCompu_44:b5:3d (08:00:27:44:b5:3d), Dst: > Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Destination: Micro-St_57:60:85 (d4:3d:7e:57:60:85) > Source: PcsCompu_44:b5:3d (08:00:27:44:b5:3d) > Type: IPv4 (0x0800) > Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.4 > Transmission Control Protocol, Src Port: 8042, Dst Port: 63868, Seq: 1, > Ack: 119, Len: 57 > Data (57 bytes) > > 0000 15 03 03 00 34 a0 b5 dc 18 cb e2 21 8b 97 6d 9d ....4......!..m. > 0010 48 d0 e4 81 09 c2 1b b4 8c 2e 90 59 11 f7 f7 e8 H..........Y.... > 0020 86 7b 1a 81 b9 f5 37 7b b7 00 f4 bb 4a 93 8c 9a .{....7{....J... > 0030 52 9f 1e 56 a9 6c 18 ca 66 R..V.l..f > > The hex 15 at the beginning tells us that this is an alert message. It > is for TLSv1.2 (03 03) and a length of 52 decimal bytes == 00 34 hex. > > This is wrong! An unencrypted alert always has a length of 2 bytes - > which means this is an *encrypted* alert!! The server should not be > encrypting anything at this stage in the handshake. > > It looks to me like the server is confused and thinks it is still > talking to the first client. Did you reuse the SSL object from one > connection to the next? Your code sample looks like maybe you did. Don't > do that! Create a new SSL object for each connection. Or if you *must* > reuse the SSL object (I can't think why) then call SSL_clear() on it. Ok the call for SSL_clear() apparently works. Thanks a lot. To make the code clean, I will re-instantiate SSL object for each connection. I do not have any specific reasons to keep SSL object alive after each connection. It just that I do not want to re-inialize the context. In the old version, it works very well without it.... > > Matt > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
