LAUNCHXL-CC3235SF: HTTPGet demo works with http, fails with https

Hi,

In order for the httpget example to work with a server secured with HTTPS, you will need to make a few modifications beyond just changing the URL. Please take a look at this post for the full list of changes required:

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/663977/2444798#2444798

Most notably, you will need to provide the correct root CA so that the CC3220 can authenticate your server's certificate chain. You can either use your browser to see what your target URL uses, or sniff the TLS handshake that you do on your PC when connecting to it. You can implement a handler in the socket event callback to display which root CA cert is needed, as described in this post: https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/p/686966/2531683#2531683

Let me know if you still have issues with the httpget example after implementing those changes.

Regards,

Michael

I have gotten some level of success, but still have an issue. Using the HTTPS www-example-com site (how do you put a link in this forum without it including the site?!?) it retrieves it and displays the body correctly. However, the actually HTTPS site I need to use, and also testing with apple-com, it fails with error SL_OTHER_SIDE_CLOSE_SSL_DATA_NOT_ENCRYPTED (2).

I know that this is saying the remote end is closing the TLS layer, but not WHY that's happening, or if it's normal, how my code should handle it.

I've created a project that allows switching between the www-example-com and apple-com sites, and allows selecting whether the certificate is stored on the CC32xx file system or is embedded in the application code. It's available at https://github.com/jcwren/cc32xx_https_example. Perhaps others will find it useful when experimenting with HTTPS. If we find a solution as to why the above error is being thrown, I'll update the repository.

As an unrelated aside note, it is REALLY irritating that the source//ti/drivers/Display.h functionality ALWAYS includes a \r\n at the end of output when the driver is set to DisplayUartMin_vprintf(),. The addition of the \r\n should be able to be disabled by correctly implementing the DisplayUart_SCROLLING #define, shown below. This will maintain compatibility with the currently broken method, since all the demo applications I can find pass 0 as the line number in the Display_Printf() call.

void DisplayUartMin_vprintf(Display_Handle hDisplay, uint8_t line,
                            uint8_t column, char *fmt, va_list va)
{
    DisplayUart_Object  *object  = (DisplayUart_Object  *)hDisplay->object;
    DisplayUart_HWAttrs *hwAttrs = (DisplayUart_HWAttrs *)hDisplay->hwAttrs;

    uint32_t strSize = 0;

    if (SemaphoreP_pend(object->mutex, hwAttrs->mutexTimeout) == SemaphoreP_OK)
    {
        SystemP_vsnprintf(hwAttrs->strBuf, hwAttrs->strBufLen - 2, fmt, va);

        strSize = strlen(hwAttrs->strBuf);
        if (line != DisplayUart_SCROLLING)
        { 
          hwAttrs->strBuf[strSize++] = '\r';
          hwAttrs->strBuf[strSize++] = '\n';
        }
 
        UART_write(object->hUart, hwAttrs->strBuf, strSize);
        SemaphoreP_post(object->mutex);
    }
}

Also note that clicking 'Paste from Code Help' in the 'Insert code using Syntaxhighlighter' window in the code editor goes to a page with the error message "Unfortunately, the page you've requested no longer exists. Please use the search form above to locate the information you're interested in."

Michael Reymond?

Hi,

Thanks for the really helpful instructions as well as the code in your github page.

I've run what you have and encountered the same error when connecting to apple.com. It seems like there is some SSL error before the TLS handshake occurs, which is odd. I'll need to investigate this further on my end to determine why that is the case.

Just to confirm we are seeing the same thing, could you please enable NWP logs on your side:

https://processors.wiki.ti.com/index.php/CC3120_%26_CC3220_Capture_NWP_Logs

Then capture the logs of the connection to apple.com and provide those to me?

Thank you for your patience.

Regards,

Michael

I'd be happy to, but it I think the wiki is outdated.  Editing /Applications/ti//simplelink_cc32xx_sdk_3_30_01_02/source/ti/boards/CC3235S_LAUNCHXL/CC3235S_LAUNCHXL.c does not cause the changes to be included into the build. Modifying the <project>/Debug/syscfg/ti_drivers_config.c gets overwritten when the project is built.

There's a /Applications/ti/ccs920/ccs/utils/sysconfig/dist/deviceData/CC3235SF/metadata.bundle that has the code that's getting punched into the <project>/Debug/syscfg/ti_drivers_config.c file, but I can't figure out how you're actually supposed to modify it. 

Board_initHook() is called in the Board_init() function. This is a weak function, so I should be able to declare Board_initHook() in my platform.c, and include the following code?

// If your application already has UART0 configured, no need for this line 
MAP_PRCMPeripheralClkEnable(PRCM_UARTA0, PRCM_RUN_MODE_CLK);

// Mux Pin62 to mode 1 for outputing NWP logs 
MAP_PinTypeUART(PIN_62, PIN_MODE_1); 

That appeared to work. Hopefully the log contents are valid.

0211.NWP_Log.tar

Michael Reymond?

Hi,

Looking through your NWP logs and checking that against what I'm seeing on my setup, it appears that we get the same TLS error. So that confirms that I have replicated what you're seeing.

Something I noticed is that your startSNTP() function doesn't set the NWP time correctly. You need to use the sl_DeviceSet(SL_DEVICE_GENERAL, SL_DEVICE_GENERAL_DATE_TIME,..) API to set the NWP time. However, it doesn't look like the error we are getting is a certificate date verification error. I'll keep investigating this issue and give you an update by the end of the week.

Regards,

Michael

Interesting. None of the examples in the simplelink_cc32xx_sdk_3_30_01_02 directory that use SNTP use the sl_DeviceSet() function, and none of the examples that use sl_DeviceSet() support SNTP. Seems the SNTP examples should be updated to reflect that.

Looking forward to hearing the results of your investigation.

Hi,

Doing some more testing, it appears that there is some error in your code that you will need to investigate and debug on your end; the issue does not seem to originate with the CC3220 NWP or the HTTP library itself.

Taking the basic HTTPget example, and performing some simple modifications to get it to connect to apple.com and send it a get request for / appear to work on my end. Attached is the code I used:

/cfs-file/__key/communityserver-discussions-components-files/968/httpget2.c

Note that you do need to pre-flash and provide the root CA cert used to verify apple.com's server certificate to the device first before you run the code. If you import the HTTPget example and then use my code to perform that get request, do you still see the same issues?

Regards,

Michael

Finally got a chance to look at this again. Our code seems to be basically identical, with one exception. Where I call `HTTPClient_connect()`, the `HTTPClient_extSecParams` structure goes out of scope after the call. The documentation for the function does not indicate if it's required for that to persist for any remaining operations between that call and calling `HTTPClient_destroy()`. If this is the case, that needs to be documented.

I'll move that around and see if it has any impact. Other than that difference, what are you considering to be the simple modifications?

Thanks,
  --jc

Hi JC,

I'm not sure whether HTTPClient_extSecParams needs to be kept valid for the duration of the HTTPClient interaction. If you could check that and see if it fixes your issue then that would be appreciated.

There aren't really any other modifications. You can compare my provided HTTPget code against the default out of box code to see how much/little was changed.

Regards,

Michael