Bug found in offloading feature during secure MQTT
Dear Zephyr people,
I was using the zephyr socket offloading feature to test secure MQTT functionality.
As part of this, the host name is one of the options being sent via a zsock_setsockopt() call.
It turns out that due to the fact that strlen(hostname) does not include the null character, when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there, the TLS exchange failed due to host name check failing.
ret = zsock_setsockopt(client->transport.tls.sock, SOL_TLS,
TLS_HOSTNAME, tls_config->hostname,
strlen(tls_config->hostname)); =======> changing this strlen(tls_config->hostname)+1 resolved the problem
Bug on the client side:
and optlen of hostname being ignored on the server side and null character is never seen:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/sockets/sockets_tls.c#L1362
Can anyone help with what to do next because I am not sure on what side this problem should be solved?
Thanks
Laura
Hi Laura,
I’m missing in this picture what kind of offloading are you using, i. e. is TLS offloaded or only TCP, what device etc. Since you refer to a native TLS implementation, I assume it may be TCP only.
- when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there
Did you mean socket instead of server? Anyway, yes, optlen is ignored and no NULL termination is added, but the TLS_HOSTNAME option description is pretty clear, that it expects a string. So it should be the application responsibility to provide a proper C-string, with NULL termination.
Regards,
Robert
Sent: czwartek, 26 stycznia 2023 00:34
To: devel@...
Subject: [Zephyr-devel] Bug found in offloading feature during secure MQTT
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
Dear Zephyr people,
I was using the zephyr socket offloading feature to test secure MQTT functionality.
As part of this, the host name is one of the options being sent via a zsock_setsockopt() call.
It turns out that due to the fact that strlen(hostname) does not include the null character, when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there, the TLS exchange failed due to host name check failing.
ret = zsock_setsockopt(client->transport.tls.sock, SOL_TLS,
TLS_HOSTNAME, tls_config->hostname,
strlen(tls_config->hostname)); =======> changing this strlen(tls_config->hostname)+1 resolved the problem
Bug on the client side:
and optlen of hostname being ignored on the server side and null character is never seen:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/sockets/sockets_tls.c#L1362
Can anyone help with what to do next because I am not sure on what side this problem should be solved?
Thanks
Laura
Hi Robert,
Thank you for replying.
I have two processors: An STM32 and an ESP32 (the ESP32 has the networking stack and the radio chip).
For the MQTT messaging, I am creating the MQTT message using MQTT zephyr library on the STM32 and then over simple socket calls sending data to ESP32 chip.
The TLS exchange using MbedTLS happens on the ESP32 side.
I am calling the STM32 the “client” and the ESP32 the “server” per what I understand how socket offloading terminology is used.
From the STM32 side, the zephyr MQTT library code has this:
Note, how it does strlen(hostname) which does not account for the null character and when I change it to be strlen(hostname) + 1, that fixes the problem.
ret = zsock_setsockopt(client->transport.tls.sock, SOL_TLS,
TLS_HOSTNAME, tls_config->hostname,
strlen(tls_config->hostname)); =======> changing this strlen(tls_config->hostname)+1 resolved the problem
What do you think?
Thank you
Laura
From:
Lubos, Robert <Robert.Lubos@...>
Date: Thursday, January 26, 2023 at 2:27 AM
To: Laura Nayman <lnayman@...>, devel@... <devel@...>
Subject: RE: Bug found in offloading feature during secure MQTT
|
EXTERNAL EMAIL - Use caution when responding, clicking, and/or downloading attachments. |
Hi Laura,
I’m missing in this picture what kind of offloading are you using, i. e. is TLS offloaded or only TCP, what device etc. Since you refer to a native TLS implementation, I assume it may be TCP only.
- when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there
Did you mean socket instead of server? Anyway, yes, optlen is ignored and no NULL termination is added, but the TLS_HOSTNAME option description is pretty clear, that it expects a string. So it should be the application responsibility to provide a proper C-string, with NULL termination.
Regards,
Robert
Sent: czwartek, 26 stycznia 2023 00:34
To: devel@...
Subject: [Zephyr-devel] Bug found in offloading feature during secure MQTT
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
Dear Zephyr people,
I was using the zephyr socket offloading feature to test secure MQTT functionality.
As part of this, the host name is one of the options being sent via a zsock_setsockopt() call.
It turns out that due to the fact that strlen(hostname) does not include the null character, when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there, the TLS exchange failed due to host name check failing.
ret = zsock_setsockopt(client->transport.tls.sock, SOL_TLS,
TLS_HOSTNAME, tls_config->hostname,
strlen(tls_config->hostname)); =======> changing this strlen(tls_config->hostname)+1 resolved the problem
Bug on the client side:
and optlen of hostname being ignored on the server side and null character is never seen:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/sockets/sockets_tls.c#L1362
Can anyone help with what to do next because I am not sure on what side this problem should be solved?
Thanks
Laura
Hi again,
I have to admit I don’t think I fully understand your setup. I have an impression that you’re referring to some out-of-tree code here? I don’t recall having TLS offloading support for ESP32, although I may be missing something.
Anyway, I agree there were some inconsistency wrt to TLS_HOSTNAME, that hasn’t been spotted so far, as the `optlen` value is simply ignored by the native implementation. I’ve submitted https://github.com/zephyrproject-rtos/zephyr/pull/54144 to address that, hopefully it helps in your case.
Regards,
Robert
Sent: czwartek, 26 stycznia 2023 16:29
To: Lubos, Robert <Robert.Lubos@...>; devel@...
Subject: Re: Bug found in offloading feature during secure MQTT
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
Hi Robert,
Thank you for replying.
I have two processors: An STM32 and an ESP32 (the ESP32 has the networking stack and the radio chip).
For the MQTT messaging, I am creating the MQTT message using MQTT zephyr library on the STM32 and then over simple socket calls sending data to ESP32 chip.
The TLS exchange using MbedTLS happens on the ESP32 side.
I am calling the STM32 the “client” and the ESP32 the “server” per what I understand how socket offloading terminology is used.
From the STM32 side, the zephyr MQTT library code has this:
Note, how it does strlen(hostname) which does not account for the null character and when I change it to be strlen(hostname) + 1, that fixes the problem.
ret = zsock_setsockopt(client->transport.tls.sock, SOL_TLS,
TLS_HOSTNAME, tls_config->hostname,
strlen(tls_config->hostname)); =======> changing this strlen(tls_config->hostname)+1 resolved the problem
What do you think?
Thank you
Laura
From:
Lubos, Robert <Robert.Lubos@...>
Date: Thursday, January 26, 2023 at 2:27 AM
To: Laura Nayman <lnayman@...>,
devel@... <devel@...>
Subject: RE: Bug found in offloading feature during secure MQTT
|
EXTERNAL EMAIL - Use caution when responding, clicking, and/or downloading attachments. |
Hi Laura,
I’m missing in this picture what kind of offloading are you using, i. e. is TLS offloaded or only TCP, what device etc. Since you refer to a native TLS implementation, I assume it may be TCP only.
- when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there
Did you mean socket instead of server? Anyway, yes, optlen is ignored and no NULL termination is added, but the TLS_HOSTNAME option description is pretty clear, that it expects a string. So it should be the application responsibility to provide a proper C-string, with NULL termination.
Regards,
Robert
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
Dear Zephyr people,
I was using the zephyr socket offloading feature to test secure MQTT functionality.
As part of this, the host name is one of the options being sent via a zsock_setsockopt() call.
It turns out that due to the fact that strlen(hostname) does not include the null character, when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there, the TLS exchange failed due to host name check failing.
ret = zsock_setsockopt(client->transport.tls.sock, SOL_TLS,
TLS_HOSTNAME, tls_config->hostname,
strlen(tls_config->hostname)); =======> changing this strlen(tls_config->hostname)+1 resolved the problem
Bug on the client side:
and optlen of hostname being ignored on the server side and null character is never seen:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/sockets/sockets_tls.c#L1362
Can anyone help with what to do next because I am not sure on what side this problem should be solved?
Thanks
Laura
Hi Robert,
Thank you so much. This is exactly what I needed.
-Laura
From:
Lubos, Robert <Robert.Lubos@...>
Date: Thursday, January 26, 2023 at 10:18 AM
To: Laura Nayman <lnayman@...>, devel@... <devel@...>
Subject: RE: Bug found in offloading feature during secure MQTT
|
EXTERNAL EMAIL - Use caution when responding, clicking, and/or downloading attachments. |
Hi again,
I have to admit I don’t think I fully understand your setup. I have an impression that you’re referring to some out-of-tree code here? I don’t recall having TLS offloading support for ESP32, although I may be missing something.
Anyway, I agree there were some inconsistency wrt to TLS_HOSTNAME, that hasn’t been spotted so far, as the `optlen` value is simply ignored by the native implementation. I’ve submitted https://github.com/zephyrproject-rtos/zephyr/pull/54144 to address that, hopefully it helps in your case.
Regards,
Robert
Sent: czwartek, 26 stycznia 2023 16:29
To: Lubos, Robert <Robert.Lubos@...>; devel@...
Subject: Re: Bug found in offloading feature during secure MQTT
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
Hi Robert,
Thank you for replying.
I have two processors: An STM32 and an ESP32 (the ESP32 has the networking stack and the radio chip).
For the MQTT messaging, I am creating the MQTT message using MQTT zephyr library on the STM32 and then over simple socket calls sending data to ESP32 chip.
The TLS exchange using MbedTLS happens on the ESP32 side.
I am calling the STM32 the “client” and the ESP32 the “server” per what I understand how socket offloading terminology is used.
From the STM32 side, the zephyr MQTT library code has this:
Note, how it does strlen(hostname) which does not account for the null character and when I change it to be strlen(hostname) + 1, that fixes the problem.
ret = zsock_setsockopt(client->transport.tls.sock, SOL_TLS,
TLS_HOSTNAME, tls_config->hostname,
strlen(tls_config->hostname)); =======> changing this strlen(tls_config->hostname)+1 resolved the problem
What do you think?
Thank you
Laura
From:
Lubos, Robert <Robert.Lubos@...>
Date: Thursday, January 26, 2023 at 2:27 AM
To: Laura Nayman <lnayman@...>,
devel@... <devel@...>
Subject: RE: Bug found in offloading feature during secure MQTT
|
EXTERNAL EMAIL - Use caution when responding, clicking, and/or downloading attachments. |
Hi Laura,
I’m missing in this picture what kind of offloading are you using, i. e. is TLS offloaded or only TCP, what device etc. Since you refer to a native TLS implementation, I assume it may be TCP only.
- when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there
Did you mean socket instead of server? Anyway, yes, optlen is ignored and no NULL termination is added, but the TLS_HOSTNAME option description is pretty clear, that it expects a string. So it should be the application responsibility to provide a proper C-string, with NULL termination.
Regards,
Robert
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
Dear Zephyr people,
I was using the zephyr socket offloading feature to test secure MQTT functionality.
As part of this, the host name is one of the options being sent via a zsock_setsockopt() call.
It turns out that due to the fact that strlen(hostname) does not include the null character, when the host name was received on the server end and because the server side ignored the optlen and did not add the null character there, the TLS exchange failed due to host name check failing.
ret = zsock_setsockopt(client->transport.tls.sock, SOL_TLS,
TLS_HOSTNAME, tls_config->hostname,
strlen(tls_config->hostname)); =======> changing this strlen(tls_config->hostname)+1 resolved the problem
Bug on the client side:
and optlen of hostname being ignored on the server side and null character is never seen:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/sockets/sockets_tls.c#L1362
Can anyone help with what to do next because I am not sure on what side this problem should be solved?
Thanks
Laura