11 Replies Latest reply on May 21, 2018 12:01 AM by axel.lin_1746341

    sdk-6.1 TLS-v1.2 problem

    axel.lin_1746341

      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.

        • 1. Re: sdk-6.1 TLS-v1.2 problem
          axel.lin_1746341

          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.

           

          mady grsr

          • 2. Re: sdk-6.1 TLS-v1.2 problem
            grsr

            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.

            • 3. Re: sdk-6.1 TLS-v1.2 problem
              axel.lin_1746341

              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.

              • 4. Re: sdk-6.1 TLS-v1.2 problem
                axel.lin_1746341

                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.

                • 5. Re: sdk-6.1 TLS-v1.2 problem
                  axel.lin_1746341

                  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.

                  • 6. Re: sdk-6.1 TLS-v1.2 problem
                    grsr

                    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.

                    • 7. Re: sdk-6.1 TLS-v1.2 problem
                      axel.lin_1746341

                      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

                      • 8. Re: sdk-6.1 TLS-v1.2 problem
                        grsr

                        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.

                        • 9. Re: sdk-6.1 TLS-v1.2 problem
                          axel.lin_1746341

                          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.

                          • 10. Re: sdk-6.1 TLS-v1.2 problem
                            grsr

                            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?

                            • 11. Re: sdk-6.1 TLS-v1.2 problem
                              axel.lin_1746341

                              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+.