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

Putting a private key on the device represents a HUGE security flaw #52

Open
reidkersey opened this issue Jan 24, 2019 · 4 comments
Open

Comments

@reidkersey
Copy link

The ESP8266 is capable of using TLS 1.2 via the use of WiFiClientSecure, and then adding in IoT certificates properly via the use of espClient.setCertificate, espClient.setPrivateKey & espClient.setCACert.

While this project still works for people using older versions of the ESP8266, the readme should be amended to state that a proper connection using TLS 1.2 can now be accomplished. Examples of how this is done can be found here: https://github.com/copercini/esp8266-aws_iot

@odelot
Copy link
Owner

odelot commented Jan 28, 2019

I updated the readme!

You don't need to use your private key, you can use AWS STS Temporary Credential, obtained from a web-service that uses the private key to generate temporary credentials.

@apicquot
Copy link
Contributor

Thew TLS1.2 with certificate works but is super slow (~7seconds). Your solution may still be a very good option.

@WeaVaer
Copy link
Contributor

WeaVaer commented Apr 21, 2019

@odelot ~ 48 hours ago, Amazon decided to (maybe by error) disable access to websocket services without tokens as many people using ESP-8266 and your library successfully for a time. All devices went offline with SSL handshake errors. Many people felt it and was searching for solutions, including rising voices on AWS forums who use your library. (Actually one of the entries there was by you, I think and I have an entry there also, by Nail)

An hour ago, they reverted back and the devices are online again. This incident was similar to the change of certificates on AWS at the end of 2018, but we were able to continue working with your library then and was happy until 2 days ago :) They did something (I honestly think it was a mistake, since enforcing the same rules on websocket access to mqtt really was a dumb thing to do IMHO). Anyway somebody should have shouted enough so they reverted it back.

But this incident definitely shows the need to have another methodology to continue to work with AWS. The proposed way in copercini's approach and some other guys who use similar approaches works but this brings the huge problem of creating 3 certs per new device, upload them to the device, create a thing, attach a policy etc a cumbersome work or as an alternative use their just-in time provisioning or fleet management services but then you pay more to AWS for that. Too much work and not really needed.

The method of using your library and getting temporary certs from AWS STS is a very useful solution, I think, and gives you huge flexibility. It is the best option practically, and we support it good. Thanks for your efforts of providing your work to the community.
Although you have a notice in 'read.me' about that; it would be awesome if there is a crude basic example of doing so among examples in this repo.

Thanks

@WeaVaer
Copy link
Contributor

WeaVaer commented May 3, 2019

It seems that we will have to upgrade ESP8266 core to 2.5.0 in order to be able to continue working with AWS and need to do it fast since the last change to mqtt services that was rolled-back maybe rolled forward real soon. I hope ESP core 2.5.0 has become mature and bug-free enough to do the migration upon.

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

4 participants