-->
Page 1 of 3

ESP8266httpUpdate HTTPS?

PostPosted: Sat Feb 17, 2018 4:12 pm
by androidfanboy
Hi there,

I know this is a big question for a lot of people as well, but I haven't found a straight answer to this anywhere, so I'll attempt to ask it here:

The ESP8266httpUpdate library works great for HTTP and also for HTTPS by supplying a fingerprint. However, in the event that the fingerprint changes, everything's screwed up. This is quite awful and would require re-flashing firmware with a new fingerprint. Is there any way to safely (from a security standpoint) grab firmware files from the server? Using HTTP is a no-go since it's not "safe", even with basic username/password authentication, and HTTPS requires the fingerprint. Is there a way to use HTTPS without using the fingerprint and just use a secret key as authentication? Would that be safe?

Thanks!

Re: ESP8266httpUpdate HTTPS?

PostPosted: Sat Feb 17, 2018 7:19 pm
by tele_player
I’m not arguing, just trying to understand.

What specific type of attack are you trying to prevent?

Re: ESP8266httpUpdate HTTPS?

PostPosted: Sat Feb 17, 2018 10:17 pm
by androidfanboy
Good question, I'm really not an expert at such things, that's why I posted this question. What would be considered safe, good-in-practice, and not-so-safe? Really I don't foresee much of a security risk since the device would only be grabbing the file from the server when the user wants to (which isn't by any means scheduled), so it's unlikely someone would try to hijack it and corrupt the file to compromise the device, etc. I *highly* doubt anything would really happen. I think the main objective here would be to prevent the user from getting the file. Any ideas on the best method/practice for this?

Thanks!

Re: ESP8266httpUpdate HTTPS?

PostPosted: Sat Feb 17, 2018 10:22 pm
by androidfanboy
Would it be easy to edit the ESP8266httpUpdate and ESP8266HTTPClient libraries to use HTTPS without supplying a fingerprint? For some reason (and others have the same problem) it won't work without supplying a fingerprint. However, the WiFiClientSecure library works fine without a fingerprint. Why is that?