odelot / aws-mqtt-websockets

Implementation of a middleware to use AWS MQTT service through websockets, aiming the ESP8266 plataform
GNU Lesser General Public License v3.0
231 stars 67 forks source link

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

Open reidkersey opened 5 years ago

reidkersey commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

WeaVaer commented 5 years ago

@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 commented 5 years ago

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.