Multiple reconnection in OpenSSL 1.1.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple reconnection in OpenSSL 1.1.0

Huy Cong Vu
Hi everyone,

Recently I have problem when trying to update my OpenSSL library from 1.0.1f to 1.1.0g.

I have a server that runs 24/24 and receive connections from only 1 source, and 1 connection at a time, nothing really fancy, but it worked very well in OpenSSL 1.0.1f version. In 1.1.0g, the connection is establish and runs perfectly the 1st time. And the 2nd time the client try to connect, after the SSL connection is establish, SSL_read cannot return -1, and have no errors (checked with SSL_get_errors...)

My server runs on Linux 14.04, while my client runs on Windows 7, both with OpenSSL 1.1.0.

If anyone have an idea what happened, I would be glad to know, please tell me if you need any details.

Here the principal code snipset (I don't have the certificate verification code snip here, but it was there, and it always works so I guess there no point repost it now):

+ Some initial configurations:

SSL_CTX* ctx_in;
const SSL_METHOD *method;
OpenSSL_add_all_algorithms();
SSL_load_error_strings();  
method = TLS_server_method();
ctx_in = SSL_CTX_new(method);

//Setup trusted certs & list of clients CA
SSL_CTX_set_verify(ctx_in, SSL_VERIFY_PEER, NULL);
SSL_CTX_set_verify_depth(ctx_in, 1); //our certificate chain contain only 1 more root CA
//Load issuer certificate from memory
X509_STORE* store = SSL_CTX_get_cert_store(ctx_in);
X509_STORE_add_cert(store, certinMem(caVerifClientReal);
SSL_CTX_set_client_CA_list(ctx_in, NULL);
SSL_CTX_add_client_CA(ctx_in, certinMem(pubClientReal));

//Setup curves parameters
EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1);
SSL_CTX_set_tmp_ecdh (ctx_in, ecdh);
EC_KEY_free(ecdh);

//Set options
SSL_CTX_set_options(ctx_in, SSL_OP_SINGLE_ECDH_USE && SSL_MODE_AUTO_RETRY);

...

+ Main loop:

char buf[1024];
struct sockaddr_in addr; //client
socklen_t len = sizeof(addr);

while (1)
{
    //initialize buffer
    buf[0] = '\0';
    int client = accept(server, reinterpret_cast<struct sockaddr*>(&addr), &len);

    if (-1 != client)
    {
        //set SSL security
        const char* const PREFERRED_CIPHERS = "ECDHE-RSA-AES256-SHA"; //define cipher suite used for SSL connection
        SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);

        //set SSL socket
        SSL_set_fd(ssl, client);      /* set connection socket to SSL state */

        if (SSL_accept(ssl) == FAIL) //waits for a client to initiate the handshake
        {/* do SSL-protocol accept */
            ERR_print_errors_fp(stderr);
        }
        else
        {
            verifCerts(ssl);
            int ret = -1;
            ret = SSL_do_handshake(ssl); //check connection
            if (ret <= 0)
            {
                ERR_print_errors_fp(stderr);
            }
            else
            {
                //wait on buffer
                int bytes = SSL_read(ssl, buf, sizeof(buf));
                //here bytes return -1, and there is no error with SSL_get_errors
               
            }
        }
        sd = SSL_get_fd(ssl);       /* get socket connection */
        close(sd);          /* close connection */
}

Huy-Cong VU
Platform hardware member
Network administrator
Wandercraft
09 72 58 77 03
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Matt Caswell-2


On 16/01/18 10:31, Huy Cong Vu wrote:
> OpenSSL_add_all_algorithms();
> SSL_load_error_strings();

You do not need to make the above two calls in 1.1.0. They are called
automatically.

> //Setup curves parameters
> EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1);
> SSL_CTX_set_tmp_ecdh (ctx_in, ecdh);
> EC_KEY_free(ecdh);

You do not need to do this in 1.1.0. Curve parameters are set up
automatically.


>
> //Set options
> SSL_CTX_set_options(ctx_in, SSL_OP_SINGLE_ECDH_USE && SSL_MODE_AUTO_RETRY);

You are using logical && here instead of boolean |. This will mean that
these options are not correctly set. In any case SSL_OP_SINGLE_ECDH_USE
is not needed and is unused in 1.1.0 (it has the value 0). This is the
default (and only) mode of operation any way for 1.1.0.

>                 //wait on buffer
> int bytes = SSL_read(ssl, buf, sizeof(buf));
>                 //here bytes return -1, and there is no error with SSL_get_errors

Try calling ERR_print_errors_fp() here to see if you get any clues.

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Huy Cong Vu
On 16/01/18 10:31, Huy Cong Vu wrote:
> OpenSSL_add_all_algorithms();
> SSL_load_error_strings();

You do not need to make the above two calls in 1.1.0. They are called
automatically.

> //Setup curves parameters
> EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1);
> SSL_CTX_set_tmp_ecdh (ctx_in, ecdh);
> EC_KEY_free(ecdh);

You do not need to do this in 1.1.0. Curve parameters are set up
automatically.

>
> //Set options
> SSL_CTX_set_options(ctx_in, SSL_OP_SINGLE_ECDH_USE && SSL_MODE_AUTO_RETRY);

You are using logical && here instead of boolean |. This will mean that
these options are not correctly set. In any case SSL_OP_SINGLE_ECDH_USE
is not needed and is unused in 1.1.0 (it has the value 0). This is the
default (and only) mode of operation any way for 1.1.0.

>                 //wait on buffer
> int bytes = SSL_read(ssl, buf, sizeof(buf));
>                 //here bytes return -1, and there is no error with SSL_get_errors

Try calling ERR_print_errors_fp() here to see if you get any clues.

Thanks for the advice, I got these as error:
1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:210
1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:ssl/record/ssl3_record.c:375

Does it means my configuration is not correct, or not synchronized between client and server?

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
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Matt Caswell-2


On 16/01/18 13:35, Huy Cong Vu wrote:
> Thanks for the advice, I got these as error:
> 1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:210
> 1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:ssl/record/ssl3_record.c:375
>
> Does it means my configuration is not correct, or not synchronized between client and server?

It means the data OpenSSL is trying to read looks incorrectly formatted.
This should never normally happen with two correctly working endpoints.
The first error will normally immediately result in an alert being sent
and the function call failing - meaning that you'd never get to hit the
second error. I can't see a way of getting both those errors in a single
function call - which might suggest some earlier function call has
failed and the error message is still on the error queue when you call
SSL_read().

A couple of things to try:

- Try calling ERR_print_errors_fp() *before* the call to SSL_read() as
well, to verify there are no errors already in the queue
- A wireshark trace of the communication between the two endpoints might
be helpful to figure out what is going wrong

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Huy Cong Vu

----- Mail original -----
> De: "Matt Caswell" <[hidden email]>
> À: "openssl-users" <[hidden email]>
> Envoyé: Mardi 16 Janvier 2018 14:57:28
> Objet: Re: [openssl-users] Multiple reconnection in OpenSSL 1.1.0

> On 16/01/18 13:35, Huy Cong Vu wrote:
>> Thanks for the advice, I got these as error:
>> 1408F10B:SSL routines:ssl3_get_record:wrong version
>> number:ssl/record/ssl3_record.c:210
>> 1408F119:SSL routines:ssl3_get_record:decryption failed or bad record
>> mac:ssl/record/ssl3_record.c:375
>>
>> Does it means my configuration is not correct, or not synchronized between
>> client and server?
>
> It means the data OpenSSL is trying to read looks incorrectly formatted.
> This should never normally happen with two correctly working endpoints.
> The first error will normally immediately result in an alert being sent
> and the function call failing - meaning that you'd never get to hit the
> second error. I can't see a way of getting both those errors in a single
> function call - which might suggest some earlier function call has
> failed and the error message is still on the error queue when you call
> SSL_read().

They are not generated in a single function call. Sorry, I wans't clear.
Like I said, I have a main loop of server that receive requests (once at a time) from the same client. The 1st connection is correct, as always, and all the later connections give one of these 2 errors.

>
> A couple of things to try:
>
> - Try calling ERR_print_errors_fp() *before* the call to SSL_read() as
> well, to verify there are no errors already in the queue
> - A wireshark trace of the communication between the two endpoints might
> be helpful to figure out what is going wrong

ERR_print_errors_fp() before call of SSL_read returns nothing, which should be a good new...
By browsing Wireshark, I jump into a suspect packet from client that contains a RST flags after 1st connection:
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

Does this help?

>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Huy-Cong VU
Platform hardware member
Network administrator
Wandercraft
09 72 58 77 03
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Matt Caswell-2


On 16/01/18 15:15, Huy Cong Vu wrote:
>> - A wireshark trace of the communication between the two endpoints might
>> be helpful to figure out what is going wrong
>
> ERR_print_errors_fp() before call of SSL_read returns nothing, which should be a good new...
> By browsing Wireshark, I jump into a suspect packet from client that contains a RST flags after 1st connection:
> 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
>
> Does this help?

Please can you attach the actual trace? Or send it direct to me if it is
large.

Thanks

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Huy Cong Vu


Huy-Cong VU
Platform hardware member
Network administrator
Wandercraft
09 72 58 77 03

----- Mail original -----
> De: "Matt Caswell" <[hidden email]>
> À: "openssl-users" <[hidden email]>
> Envoyé: Mardi 16 Janvier 2018 16:17:47
> Objet: Re: [openssl-users] Multiple reconnection in OpenSSL 1.1.0

> On 16/01/18 15:15, Huy Cong Vu wrote:
>>> - A wireshark trace of the communication between the two endpoints might
>>> be helpful to figure out what is going wrong
>>
>> ERR_print_errors_fp() before call of SSL_read returns nothing, which should be a
>> good new...
>> By browsing Wireshark, I jump into a suspect packet from client that contains a
>> RST flags after 1st connection:
>> 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
>>
>> Does this help?
>
> Please can you attach the actual trace? Or send it direct to me if it is
> large.

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.

Thanks a lot

>
> Thanks
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Matt Caswell-2


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
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Huy Cong Vu
----- Mail original -----
> De: "Matt Caswell" <[hidden email]>
> À: "openssl-users" <[hidden email]>
> 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.@.)])...
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Matt Caswell-2


On 16/01/18 16:22, Huy Cong Vu wrote:
> 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....

Interesting. There has been no change in the API in this regards. You
have never been "allowed" to reuse an SSL object without first calling
SSL_clear() - that's the whole point of that function (and its been
around since forever). It sounds like you were "lucky" before :-)

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Multiple reconnection in OpenSSL 1.1.0

Huy Cong Vu
----- Mail original -----
> De: "Matt Caswell" <[hidden email]>
> À: "openssl-users" <[hidden email]>
> Envoyé: Mardi 16 Janvier 2018 17:49:02
> Objet: Re: [openssl-users] Multiple reconnection in OpenSSL 1.1.0

> On 16/01/18 16:22, Huy Cong Vu wrote:
>> 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....
>
> Interesting. There has been no change in the API in this regards. You
> have never been "allowed" to reuse an SSL object without first calling
> SSL_clear() - that's the whole point of that function (and its been
> around since forever). It sounds like you were "lucky" before :-)
>

Maybe, but it lasts for a very long time :)
Anyway, thanks a lot for your help mate.

> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Huy-Cong VU
Platform hardware member
Network administrator
Wandercraft
09 72 58 77 03
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users