[openssl-users] Multiple reconnection in OpenSSL 1.1.0

Tue Jan 16 15:58:11 UTC 2018

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.

Matt