fishy-wifi
fishy-wifi copied to clipboard
hamishcunningham
Implement SSL in joinme
Use SSL in joinme to secure AP credentials.
Looks like this will require switching from ESPWebServer to ESPWebServerAsync as ESPWebServer has no SSL capabilities.
A big question is how to get an SSL cert signed by a root CA for each device to avoid triggering warnings from browsers.
One option may be to use captive portal from #11 to masquerade as some domain in the form of esp<mac address>.<some TLD we control> ( e.g. esp240ac40c1f79.wegrow.social ) which would allow one cert per device, and let us use certs issued for that subdomain from a service such as letsencrypt.
However this would not allow SSL once joined to a network unless we are the primary DNS server ( we could create a DNS record for each subdomain pointing to the devices local IP if it is static, however this might interfere with cert issuing ).
Another issue is the matter of renewing SSL certs, especially if using letsencrypt or similar services as their certs expire in 90 days.
Another, simpler, option is to issue a self signed cert to each device when it is provisioned, and get users to add the root cert to their device(s). However getting users to add our root cert is likely to be a pain point, and without adding our root the user will see a browser warning page.
In general the problem of acquiring and maintaining SSL certs on IoT devices appears to be currently unsolved, and no CAs provide a simple/supported way to do so.
Please comment with any suggestions on cert management you have.
Great write up of the major issues - as you state, this is a mostly unsolved issue and therefore a hard problem. I think we can live with the 90 day validity - program device just before shipping with new cert and tell users they should connect to device pronto. After the device has upstream connectivity it can get a certificate update every 60 days? @hamishcunningham can you install certbot on the wegrow.social or com3505 servers to use letsencrypt? My reading of the letsencrypt docs suggest that we can automate the request and provision of subdomain certs once the domain has been validated - for 30 days at least. Oh and tiny thing, can you add the waterelf32 and enhancement labels to this issue please - ta!
This might be more problematic than I thought as it seems only the esp8266 version of the library I was looking at has ssl support, as the ESPAsyncTcp library on which it depends is missing ssl in the esp32 port, but I have put in an issue about it over at https://github.com/me-no-dev/AsyncTCP/issues/8 . In the meantime I may have to evaluate some other webserver options (if there are any).
Great analysis! This may be a little beyond the curve at present (though I confess I didn't know about letsencrypt and at first glance don't properly understand how it would solve the problem). This post is interesting though, especially in a WaterElf context where we typically have a Raspberry Pi gateway on the same network: http://www.esp8266.com/viewtopic.php?t=2439&p=14229
Apart from that, and in the context of devices without gateways, I wonder if we can leverage the physical access we assume users have along with some sort of tunnelling over HTTP to secure data transfers "out of band" (i.e. without SSL but with end-to-end encryption)? E.g. button press sync'd with UI prompt to create shared secret or summut (we can add OLED boards to the elf easily enough). <disclaimer>This may be one of those "oh yes I'll implement my own crypto!" stupid ideas!</disclaimer>
As this issue seems dependant on the ESPAsyncTCP project, and they have been responsive but unable to give timescale - I suggest we 'park' this one for now - leave it open perhaps but un-assign yourself to indicate giving up ownership?