[openssl-users] Multiple reconnection in OpenSSL 1.1.0
Huy Cong Vu
huy-cong.vu at wandercraft.eu
Tue Jan 16 16:22:33 UTC 2018
----- Mail original -----
> De: "Matt Caswell" <matt at openssl.org>
> À: "openssl-users" <openssl-users at openssl.org>
> Envoyé: Mardi 16 Janvier 2018 16:58:11
> Objet: Re: [openssl-users] 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. at .)])...
> 0020 41 4b 14 a2 26 08 e7 c1 91 40 c2 00 00 04 c0 14 AK..&.... at ......
> 0030 00 ff 01 00 00 40 00 0b 00 04 03 00 01 02 00 0a ..... at ..........
> 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
More information about the openssl-users
mailing list