Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use publicly signed certificate on https://hw.airgradient.com #273

Open
MallocArray opened this issue Dec 14, 2024 · 5 comments
Open

Use publicly signed certificate on https://hw.airgradient.com #273

MallocArray opened this issue Dec 14, 2024 · 5 comments

Comments

@MallocArray
Copy link
Contributor

On the main website, a LetsEncrypt cert is used to be publicly trusted.

On the API endpoint, it is only a self-signed certificate and not one that can be fully trusted by an end client.

Update the cert to also use LetsEncrypt so everything is secure and publicly signed

image

image

@samuelbles07
Copy link
Collaborator

The hw subdomain only used by airgradient monitor (not browser, etc). The problem of using Authorized CA is we need to re-new the certificate every X time, and it will have a problem on the device itself if we don't have a rolling certificate scenario.
As far as i know, as long as the client only accept the certificate from hw.airgradient.com domain, i don't think it will have a problem.

@MallocArray
Copy link
Contributor Author

If the device trusts the root certificate of Lets Encrypt "ISRG Root X1" and the intermediate CAs, then it will trust any rolling certificate that is issued. And if you aren't validating the current self signed certificate, then there would be no further harm by using a proper certificate.

It sounds like you don't think security is communication is important, but that feels like just avoiding doing the proper thing. If traffic to and from the device isn't encrypted and verified to be the proper endpoint, it would be possible for someone to setup a malicious configuration server to send invalid configs to devices, changing calibrations, enabling/disabling LEDs that the user did not intend, etc.

This is the end user's data and it should be protected with reasonable efforts. You already use Lets Encrypt for the main site, so due diligence should be done to properly protect all of the data.

@samuelbles07
Copy link
Collaborator

samuelbles07 commented Dec 17, 2024

And if you aren't validating the current self signed certificate, then there would be no further harm by using a proper certificate.

I totally agree with you on above part. On the latest firmware master branch, the certificate is indeed verified. What i mean is, i don't think there's any difference when we are using for example Lets Encrypt and self signed certificate when both certificate is validated/verified on the client side.

If the device trusts the root certificate of Lets Encrypt "ISRG Root X1" and the intermediate CAs, then it will trust any rolling certificate that is issued.

I guess we need to look further on this

@MallocArray
Copy link
Contributor Author

I run mine with ESPHome firmware and have not been including the self-signed certificate, so validation is not possible. If it were publicly signed, then ESP-IDF can be used to include root CA bundle from Mozilla which will trust the Lets Encrypt certs.

@samuelbles07
Copy link
Collaborator

I only know little about ESPHome, but if it can include ESP-IDF code on it, then maybe you can include this root CA for validation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants