add code to initialize default values for internal/protected variable…#8
Merged
alkonosst merged 2 commits intoalkonosst:masterfrom Oct 6, 2023
Conversation
…s in the SSLClientESP32 class, improve the security of the code
Owner
|
Thank you :) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…s in the SSLClientESP32 class, improve the security of the code
Description
All the private/protected variables need to be initialized to default values as following:
(in the SSLClientESP32.h file)
Also, insert
_use_insecure = false;to theSSLClientESP32::SSLClientESP32(Client* client)constructor in theSSLClientESP32.cppin order to prevent an accidently insecure behavior (skip certificate validation without users notice) when initialize the object at run time (for example, the users declare and initialize an SSLClientESP32 object inside a local function).Motivation and context
The following usage will lead to unexpected insecure behavior:
The above code will successfully connect and perform a GET request even with the invalid/wrong
root_ca, without the users' notice.How this has been tested?
This library will do correctly as expected if users declare and initiallize a
SSLClientESP32 sslClient(&baseClient);at the global scope. But it fail to verify theroot_caif you initiallize the object in a local scope (so it will initiallize at runtime).After do some small modifications as decribed in the first section, I've tested the above code with a valid root_ca --> it will perform verification successfully. If the
root_cais invalid it will reject the connection.I've also tested other usual use-cases as indicated in the documentation, it still works. That means my modification does not break any previous code.
Formally, the library will wrongly fallback to
insecuremode, and thesetCACert(root_ca)never takes effect when initiallizing the object locally.Tested with:
I would like to thank the author of this library for his time and contribution!