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. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
