2021-05-14 12:36 PM
I am trying to implement an TLS HTTPS server based on this HTTP Web Server sample:
I have been trying to convert the above sample to TLS HTTPS from this example code functions from the same GIT hub:
But I can't get the server to respond correctly from the clientHello, it responds with a short packet that should have been a serverHello. Using Wireshark to verify this.
The HTTP sample works fine on the STM32H735G-DK as it should.
I have also tried adapting the process described in Small Example System (TLS Web Server):
https://docs.microsoft.com/en-us/azure/rtos/netx-duo/netx-secure-tls/chapter2
The example above uses different functions than the STM32 hosted examples, but still have the same broken server response. I am sort of stuck now. I am posting this here because it looks like STM employees ported the Azure middleware over from Microsoft.
Solved! Go to Solution.
2021-05-24 11:08 AM
Adding a #define NX_SECURE_ENABLE_AEAD_CIPHER to nx_user.h fixed the issue and now has a total of 7 cipher suites available.
2021-05-20 12:40 PM
The response packet isn't corrupted. The issue seems to be there are only 4 supported cipher suites on the STM32 NetXDuo HTTPS server, and all modern browsers like Chrome, Edge, & Firefox deny the use of those 4 available. They are:
0xC023 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
0xC027 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
0x003d TLS_RSA_WITH_AES_256_CBC_SHA256
0x003c TLS_RSA_WITH_AES_128_CBC_SHA256
Microsoft Internet Explorer does work. The remaining question is why only those 4 and is there a way to add newer cipher suites without trashing the NetXDuo platform?
2021-05-24 11:08 AM
Adding a #define NX_SECURE_ENABLE_AEAD_CIPHER to nx_user.h fixed the issue and now has a total of 7 cipher suites available.