espconn_secure/tls: eliminate funky flash game

[nwf]

Missing feature

I would like to propose that the current tls.cert.verify and tls.cert.auth API is unfortunate. It directly accesses particular sectors of flash and is holographically embedded within both app/mbedtls/app/espconn_secure.c and app/mbedtls/app/espconn_mbedtls.c. I would prefer, instead, I think, either a more elaborate per-connection configuration mechanism or, failing that, that the API be such that these two functions take Lua functions that return certificates or keys when invoked:

tls.cert.verify(function(ix) if ix == 1 then return file:read("ca.pem") end end)
tls.cert.auth(function(ix) ... end) -- ix 0: private key, 1: cert, 2+: chain elements

We can encode the current behavior by making the PEM-string forms of these functions write to a particular name in SPIFFS and make the boolean forms install default functions that read those files.

Justification

At least in the test harness I'm working on, there's a fair bit of juggling of SSL keys and certs, and I'd much rather have these as files in the SPIFFS than in particular sectors of flash.

Workarounds

Lots and lots of flash overwrites.

[TerryE]

@nwk, are you aware of the platform_rcr functions (read/write/delete) ? But that aside, I also feel on balance that it is a lot simpler to use SPIFFS as the repository for such data.

[nwf]

I was not aware of the platform_rcr functions, no. If we wanted to store the certs over there, I'd prefer that we expose the RCR records to Lua (perhaps as userdata rather than strings, necessarily) rather than adopt the existing, exciting flash game directly.

I admit I've stalled on actually eliminating the funky TLS flash goo because I haven't yet figured out a good replacement for the Makefile's ability to bake in a certificate:

• https://github.com/nodemcu/nodemcu-firmware/blob/master/Makefile#L402
• https://github.com/nodemcu/nodemcu-firmware/blob/master/tools/make_server_cert.py
• https://github.com/nodemcu/nodemcu-firmware/blob/8d091c476edf6ae2977a5f2a74bf5824d07d6183/app/modules/tls.c#L25

Because our build system doesn't, historically, construct LFS or SPIFFS images as part of its operation, there's presently no real other way to do this. Given the existence of RCRs.... maybe we should expose those to Lua (at least in a RO way)... hm. This may also be related to #3117 and #3128 and attendant platform support.

[TerryE]

Given the existence of RCRs.... maybe we should expose those to Lua (at least in a RO way)...

There are node read and write RCR functions but only on debug builds. The aim of the RCR interface is create a facility for *nix environment like config settings that can persist across reboots. It is fast, lean and simple; using NAND write logic. My preference would be to limit access to C API because if Lua developers abuse this then it is quite easy to leave the firmware unbootable and needing reflashed.

It isn't fully safe in that once the 4Kb page is used, the GC requires it to be erased and rewritten, which might occur every 50-100 config updates. Because it is at a fixed location, you can update it using ESPtool, and this is what nodemcu-partition does, so we could just add the extra logic to this.

[nwf]

Yea, I think having nodemcu-partition.py know how to land SSL certs into the RCR would be fine. I don't particularly see a need to update the in-RCR certs from the on-device application once they're there, given that said application could just as easily pull from SPIFFS (or, better, LFS, which avoids copying into RAM if DER certs are embedded; we could make the RCR path also avoid copying up, but that might be some unnecessary engineering).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.