sdk-6.1 TLS-v1.2 problem

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

Testing with FreeRTOS+LwIP build on 43438.

Compare to TLS-v1.1, the TLS-v1.2 https request throughput is very bad.

The number of https request sent per minute with TLSv1.1 is 14 times of TLSv1.2.

In additional, when ble scan and sending https request at the same time,

the device will hang if using TLS-v1.2.

0 Likes
11 Replies
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

axel.lin_1746341 wrote:

In additional, when ble scan and sending https request at the same time,

the device will hang if using TLS-v1.2.

After doing more testing, I believe TLS-v1.2 can block BT thread when connecting to http server.

This is a problem because if BT thread is blocked for some reason it run into GKI_exception.

I check it by checking the BLE scan result.

While TLS-v1.1 looks fine with the same test.

madygrsr

0 Likes

Which HTTP library did you use for testing? Do you have a sample application code to share? It will be easier for us to reproduce.

0 Likes

grsr wrote:

Which HTTP library did you use for testing? Do you have a sample application code to share? It will be easier for us to reproduce.

I'm not able to share my code, sorry.

I don't think it's related to the http library but related to BESL library because TLS1.1 looks fine.

I believe you can modify snip.httbin_org to send request endless and create another thread for receiving BLE data.

0 Likes

Hi grsr

I think you should fist check my statement about "TLS1.2 is extremely slow".

e.g.

you can use loop to send https request for 100 times.

Then compare the difference timing between TLS1.1 v.s. TLS1.2.

Simply modify include/wiced_defaults.h

WICED_TLS_MINOR_VERSION_MIN and WICED_TLS_MINOR_VERSION_MAX for this test.

I tested with FreeRTOS build.

0 Likes

grsr

I found the problem happens when MBEDTLS_TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is used. (which is only used by TLS-1.2)

I'm not able to test all supported ciphersuits, but I think you should check all supported ciphersuits by your SDK.

Also note, the older sdk before sdk-5.2 do not have such problem.

This looks like a regression after switching to mbedTLS.

0 Likes

I am not able to reproduce this issue. The total time taken for 100 request-responses is similar for both TLS 1.2 and TLS 1.1. I had used FreeRTOS for testing and modified httpbin snip. Here is the code used for testing:

elapsed_time1=host_rtos_get_time();

for(i=0;i<100;i++)

   {

    http_request_init( &requests[0], &client, HTTP_GET, request_uris[0], HTTP_1_1 );

    http_request_write_header( &requests[0], &header[0], 1 );

    http_request_write_end_header( &requests[0] );

    http_request_flush( &requests[0] );

    wiced_rtos_get_semaphore(&sem,WICED_WAIT_FOREVER);

   }

elapsed_time2=host_rtos_get_time();

The semaphore would be set when the HTTP_DATA_RECEIVED event was received. Timestamps were recorded before and after the loop to determine the total time taken to send and receive 100 requests-responses.

0 Likes

I'm not sure if wiced BESL library has hardware dependent code.

Here is my test on CYW43438 platform: (Maybe you should try on CYW43438)

I only measure the time spent by http_client_connect() call as below:

    elapsed_time1=host_rtos_get_time();

    if ( ( result = http_client_connect( &client, (const wiced_ip_address_t*)&ip_address, SERVER_PORT, HTTP_USE_TLS, CONNECT_TIMEOUT_MS ) ) != WICED_SUCCESS )

    {

        WPRINT_APP_INFO( ( "Error: failed to connect to server: %u\n", result) );

        return;

    }

    elapsed_time2=host_rtos_get_time();

    printf("DIFF= %u\r\n", (unsigned) (elapsed_time2 - elapsed_time1));

I test twice for TLS-v1.1 and TLS-v1.2:

TLS v1.2:

www.httpbin.org is at 23.23.171.5

Connecting to www.httpbin.org

DIFF= 2375

www.httpbin.org is at 50.17.225.199

Connecting to www.httpbin.org

DIFF= 2480

TLS v1.1:

www.httpbin.org is at 54.225.64.197

Connecting to www.httpbin.org

DIFF= 953

www.httpbin.org is at 54.243.65.67

Connecting to www.httpbin.org

DIFF= 1018

0 Likes

I test the http_client_connect() call 5 times on CYW43438 with FreeRTOS and here is the numbers in ms:

TLSv1.2

2061,3652,2173,2396,2434

TLSv1.1

930,800,993,813,1227

So it took longer time to connect with TLSv1.2. I will check with the engineers on this.

Regarding my previous post, I test the 100 request-response on CYW43438 with FreeRTOS 5 times and here is the numbers in ms:

TLSv1.2

6149,5835,5881,6858,5836

TLSv1.1

6159,6153,5829,7129,6158

The numbers looked similar.

0 Likes

For the connecting time, TLSv1.2 takes double~triple time with TLSv1.1.

Then it seems strange the end result becomes almost the same for TLS1.1. and TLS 1.2 in your test.

BTW, I'm still trying to figure out why I can get 10 times difference in some environment.

0 Likes

We believe the higher connection time is due to ECC which consumes more CPU cycles irrespective of TLS 1.1 or 1.2. Can you confirm the cipher suite used in SDK before 5.2 for httpbin connection?

0 Likes

It's using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

On the same device, it looks fine if using old BESL (sdk5.1).

But has long delay after switch to mbedTLS since sdk-5.2+.

0 Likes