CC3235SF: TLS issue

Hi Cedric,

When the connection is closed by the azure server, can you try calling HTTPClient_disconnect, HTTPClient_Connect, and then HTTPClient_sendRequest to reconnect? This should ensure the proper security attributes are set.

Best regards,

Jesse

Hi Jesse,

Thanks for your reply, I will try.

Does this mean that the HTTPClient_MAX_REQUEST_ATTEMPTS mechanism in HTTPClient_sendRequest is not expected to work for such case?

Best regards,

Cédric

Hi Cédric,

The HTPPClient_MAX_REQUEST_ATTEMPTS and retryCounter within HTTPClient_sendRequest should work as expected.

Best regards,

Jesse

Hi Jesse,

As you can see in my wireshark capture above, the retry ignores the TLS and cipher setting. Even though SlNetSock_startSec is correctly called on the retry and with the correct secAttribs. Can you reproduce this?

Thanks,

Cédric

Hi Cédric,

Could you share the full wireshark capture and a code snippet of the API calls you're using to set the security attributes?

Best regards,

Jesse

Hi Jesse,

Here is the capture.

https://roomziodevops.blob.core.windows.net/public/wireshark_http_fail.pcapng

In it you will find the following sequence, in order of highlight:

1: Connection initially opened with TLS1.2 and a selection of ciphers

2: Server closes connection

3: CC3235 tries to reopen connection, but with SSLV3 and all ciphers.

//In caller: 

    sparams.method.SecureMethod = SL_SO_SEC_METHOD_TLSV1_2;

    sparams.cipher.SecureMask =
                        SL_SEC_MASK_SSL_RSA_WITH_RC4_128_SHA        |
                        SL_SEC_MASK_SSL_RSA_WITH_RC4_128_MD5        |
                        SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA    |
                        SL_SEC_MASK_TLS_RSA_WITH_AES_128_CBC_SHA256 |
                        SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA256 |
                        SL_SEC_MASK_TLS_RSA_WITH_AES_128_GCM_SHA256 ;

---------------------------------------------------------------------
// In createSecAttribs

    ret = SlNetSock_secAttribSet(secAttribHdl, SLNETSOCK_SEC_ATTRIB_CIPHERS, (char *)&exSecParams->cipher.SecureMask, sizeof(exSecParams->cipher));
    if (ret < 0)
    {
        ERROR_PRINT("%d", ret);
        goto error;
    }


    ret = SlNetSock_secAttribSet(secAttribHdl, SLNETSOCK_SEC_ATTRIB_METHOD, (char *)&exSecParams->method.SecureMethod, sizeof(exSecParams->method));
    if (ret < 0)
    {
        ERROR_PRINT("%d", ret);
        goto error;
    }

With sdk: 5.30.00.08 and corresponding service pack (sp_4.12.0.1) both the tls version and cipher list are not the expected ones

With sdk: 5.10.00.02 and corresponding service pack (sp_4.10.0.1) only the cipher list is not the expected one.

With sdk: 5.30.00.08 and old service pack ((sp_4.10.0.1) both the tls version and cipher list are not the expected ones.

This seem to indicate that the issue comes from sdk, not service pack, I could not point to some change in httpclient which could cause this.

Ok, so I rubber ducked my way out of this bug ^^ (https://rubberduckdebugging.com/)

SlNetSock_secAttribSet is not allocating a copy of the setting passed to it. So the first call works fine because variables containing TLS method is still in stack. But when the connection fails at next request the stack does not have it anymore and thus the bug appears when trying to reconnect.

Note: I copied my implementation from the certificate parts (SLNETSOCK_SEC_ATTRIB_PEER_ROOT_CA), which I suppose have the same issue. Not sure why it's not causing trouble there. I suppose the certificate setting is probably stored/applied somewhere else.

Hi Cedric,

When HTTPClient_connect is initially called, the secAttribs should be stored in the cli structure, and then retrieved from there in case of a reconnect.

Can you place a watchpoint on the cli structure to see if the secAttribs are being stored correctly and if they are being cleared or overwritten?

Best regards,

Jesse

Yes secAttribs is stored in cli structure, but the buffer in it is actually a pointer, which needs it own allocation.

In comparison, the allocation of SLNETSOCK_SEC_ATTRIB_DOMAIN_NAME is done correctly.

Hi Cédric,

We're looking into this some more and I will reply by end of day tomorrow.

Best regards,

Jesse

Hi Cédric,

We haven't been able to recreate this exact behavior yet. We tested a default secure connection using sdk 5.30.00.08 and service pack sp_4.12.0.1 and see that the device defaults to TLSv1.2.

Can you try commenting out

sparams.method.SecureMethod = SL_SO_SEC_METHOD_TLSV1_2;

A fix could also be to add code to httpclient.c that allocates and stores the security attributes similar to SLNETSOCK_SEC_ATTRIB_DOMAIN_NAME as you mentioned previously. I am looking into this as well.

Best regards,

Jesse