Adds a second TLS fingerprint to allow switching keys in TLS mode

[issacg]

This is the start of an attempt to fix the issues brought up in #2033

Things I wasn't sure about, some of which almost need to be addressed:

1. The memory addresses in Settings.h (or a revamp of how I'm storing the second key)
2. The CFG_HOLDER may need to be bumped
3. I'm not sure if an entry is needed in sonoff_post.h
4. In Settings.ino I'm unsure if I patched correctly, or if a new SettingsDefaultSet_x is needed
5. Changes made at run-time, via the Commands, don't seem to be saving. I assume that's due to the above, but not clear enough of how the settings is meant to fit together to figure it out.

[arendst]

This PR is a good reason to finally store the fingerprint as hex values saving 2/3 of the space needed and allowing for a second fingerprint without messing up the settings area.

I have to invest some time to implement.

What would be the procedure/steps to change a fingerprint when you have the possibility to use commands MqttFingerprint1 and MqttFingerprint2?

[issacg]

So we'd store both and then pad the rest as "reserved" space?I might try to have a go if I can make then time over the weekend, but don't completely understand the settings upgrade process...The use case is to have a working downgrade path. Assuming all clients use fingerprint1 and you want to rekey, you'd generate a new keypair, but not put it on the mqtt server. Then you'd update all of your devices to have fingerprint2 as the new key's sha.  Then you would roll the keypair on the mqtt server. If everything goes peachy, the clients should gracefully reconnect (or would, if we were properly verifying the certificate at connection time, instead of once at boot - that's another eventual PR) / continue working after the next device reboot. If things go wrong, though, you can roll the mqtt server back to the old cert and try again, since you can still connect your devices. Without this PR, there's no downgrade and you'd need to reflash them if you made a mistake.Does that clarify?On Mar 8, 2018 6:32 PM, Theo Arends <notifications@github.com> wrote:This PR is a good reason to finally store the fingerprint as hex values saving 2/3 of the space needed and allowing for a second fingerprint without messing up the settings area. I have to invest some time to implement. What would be the procedure/steps to change a fingerprint when you have the possibility to use commands MqttFingerprint1 and MqttFingerprint2? —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

[arendst]

So all that is needed is support for a second fingerprint and during initial connection test for both fingerprints and if one is valid continue as before. I'll make that.

In the initial issue you talk about fingerprint in relation to OTA. I do not use TLS with OTA and do not support HTTPS either. In the new ESP/Arduino library (2.4.0plus) there is works being made to get HTTPS functional. I did some testing with this but it makes tasmota unfunctional as it uses too many resources. For the short term I will not invest time in getting HTTPS usable on tiny ESP8266 devices running tasmota

[issacg]

Fixed in b51f060