Re: Multiple reconnection in OpenSSL 1.1.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux