TLS connection fails waiting for bytes after change cipher spec

[jeffthompson]

I'm using MCUXpresso IDE 11.1.1, MCUXpresso SDK 2.6.2, mbedTLS 2.13.1, and lwIP2.12. I started with the example program, lwip_httpscli_mbedtls_freertos. We're not using a client-side certificate, so I've eliminated the mbedtls_ssl_conf_own_cert() function call , as well as the parsing of the client cert, done by function mbedtls_x509_crt_parse() and client key, done by function mbedtls_pk_parse_key(). I've also added the root certs from Google Trust Services example PEM file, roots.pem. See attached httpsclient.c file.

The LS connection fails when the server sends a 'change cipher spec' to the client. See attached TLS_Connection_Fail.txt log file, generated with DEBUG_LEVEL 5 specified in httpsclient.c. I've also included a Wireshark trace of the same connection attempt. It appears that mbedTLS wants 5 more bytes than the server is giving it.

Here are my questions.

1. How the ciphersuites chosen in ksdk_mbedtls_config.h, also attached, are chosen. Could it be that one of the ciphersuites that is not included is needed?
2. How do I know whether a ciphersuite not selected in ksdk_mbedtls_config.h can be supported?
3. Is there some other explanation for the connection failure?

[kerryzhou]

Hi Jeffery Thompson,

  Please check the reply from our expert:

'sync with server’ means whether google server requests special security policies for IoT device, per our experience, most of server should require server attests devices.

Now we can't obtain any information from server, in general, server could be adaptive to client's setting, but IoT may be different to internet. because we can't get any information from server during connection, so we just try to analyze:

 1. according to the log, the client is going to verify the calculated key is same as server's, so the client encrypted a message via self-calculated key, then sent the encrypted message to server, and waiting for the server's response. but the server didn't continue to send data back to client, so one of possibilities is the server didn't correctly decrypt the encrypted message from client, but we still don't know why the server didn't correctly calculate the key during ECDHE phase.

2. according to the log, the client only skipped to send own certification to server, because it's changed by customer's project. it's only one different to the demo. does customer have the specification about IoT device from google server. upon our before experience (AWS cloud), the most of server vendors develop a different security policies for IoT domain.

Best Regards,

Kerry

[kerryzhou]

Hi Jeffery Thompson

  Already help you to check it internally, please keep patient, any updated information, will let you know.

Best Regards,

Kerry

[jeffthompson]

Kerry, I managed to recreate the issue with the minimal number of changes to the example project.

Jeff Thompson | Senior Electrical Engineer-Firmware

+1 704 752 6513 x1394

www.invue.com

[kerryzhou]

Hi Jeffery Thompson,

  Some internal updated information from our expert:

Do you want to do one-way authentication not mutual authentication? please double check, had the change been sync with server ?

According to the log during handshake, expert didn't found any incorrect process (the final fail is there because client can't receive any data from server) from client's side, so could you check the server's side whether the server reported any error message or not ?

Best Regards,

Kerry

[jeffthompson]

Kerry,

We’re only doing one-way authentication, and I don’t think it’s possible to check the server side, since that is Google Cloud. I’m not sure I understand the ‘sync with server’ part of your question, but we there is no coordination with the server side, since that is Google Cloud; we just have to work with whatever they provide.

Jeff Thompson | Senior Electrical Engineer-Firmware

+1 704 752 6513 x1394

www.invue.com

[kerryzhou]

Hi Jeffery Thompson,

  I will hep you check with out expert again about the google cloud.

  Any updated information, will let you know.

Best Regards,

Kerry

[jeffthompson]

Kerry,

Thanks for the assistance. Regarding your suggestions, when SDK 2.7.0 was released, we were too far along the development path to replace the version of SDK (2.6.2) we started with. I hope to be able to modify the lwip_httpscli_mbedtls_freertos example to use the root certificates and connection endpoint required for our application, as well as omitting the use of a client certificate (since we’re not doing two-way authentication) and try to run it on the eval kit in the next few days.

Jeff Thompson | Senior Electrical Engineer-Firmware

+1 704 752 6513 x1394

www.invue.com

[kerryzhou]

Hi Jeffery Thompson 

  Please tell me which RT chip you are using now? Do you use the nxp official RT board? Which board?

Best Regards,

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jeffthompson]

Kerry,

I’m using the MIMXrt1062DVJ6A on our custom board, which is based on the MIMXRT1060/4-EVK Board.

Jeff Thompson | Senior Electrical Engineer-Firmware

+1 704 752 6513 x1394

www.invue.com

[kerryzhou]

Hi Jeffery Thompson

  Thanks for your updated information.

  So, you are using the SDK code under :

SDK_2.7.0_EVK-MIMXRT1060\boards\evkmimxrt1060\lwip_examples\lwip_httpscli_mbedTLS\freertos

  If you run this project directly do you meet any issue or not?

  Or just when you modify the project, meet issues?

  Can you also reproduce the issue in the MIMXRT1060-EVK board?

Best Regards,

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------