Save SSL Session params (BearSSL)

[artua]

Feature request: save SSL session params between requests. It takes ~580ms to establish even insecure SSL connect() VS 20ms for HTTP connect(). If we can somehow save session params, we can dramatically decrease connection time, thus saving power for battery-powered devices.
Even more, it would be great if we can save these params between deepSleep cycles (in rtc memory).
So, requested are:
enableSessions() - to enable sessions
lastSSLParams() - to get last connection params in some form (to store on flash or rtc)

By @earlephilhower:
They're SSL sessions, like HTTP. It's dependant on the server and client, of course. As of now the BearSSL::WiFiClientSecure does NOT enable them, as they take some amount of RAM and we're not exactly drowning in available heap. The session ID is stored as well as the last encryption params by the client, and then it sends it back to the server on a reconnect sometime later who either accepts it (and uses the last settings) or starts a new negotiation. If there's a real demand I (or someone else!) can add a patch that adds a "bool enableSessions(uint count)" method.

[earlephilhower]

I did a little further checking and, while there is an optional cache for SSL sessions at the server, for the client there's obviously only one and it's stored in the BearSSL privates. This means if the same BearSSL::WiFiClientSecure object was used (i.e. it was a global or on the heap and not regenerated on each connection) it could keep this, assuming the internal private BearSSL object was preserved.

Today that object is cleared and free'd on a .close(), so it would require doing that in the destructor as well as checking on connect if there was a pre-existing BearSSL client private available.

Once that's done, it should "just work."

[artua]

So if I reuse the same BearSSL client without issuing close() it should connect with cached session?

…

On Thu, Jun 7, 2018 at 8:21 PM Earle F. Philhower, III < ***@***.***> wrote: I did a little further checking and, while there is an optional cache for SSL sessions at the *server*, for the client there's obviously only one and it's stored in the BearSSL privates. This means if the same BearSSL::WiFiClientSecure object was used (i.e. it was a global or on the heap and not regenerated on each connection) it could keep this, assuming the internal private BearSSL object was preserved. Today that object is cleared and free'd on a .close(), so it would require doing that in the destructor as well as checking on connect if there was a pre-existing BearSSL client private available. Once that's done, it should "just work." — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4796 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGV_3SZ-atNhgHeR6T3q4YABuj9UV0Nqks5t6WETgaJpZM4Uepp6> .

[earlephilhower]

Unfortunately not, @artua . If you issue a connect() on an object that's already connected, the first thing it does is close(). This addition will require a library code change.

[artua]

Any chance to save session options to connect later with the same server?

…

On Thu, Jun 7, 2018 at 9:48 PM Earle F. Philhower, III < ***@***.***> wrote: Unfortunately not, @artua <https://github.com/artua> . If you issue a connect() on an object that's already connected, the first thing it does is close(). This addition will require a library code change. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4796 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGV_3a29_saoX0BmM5-ZK-I3Gf-moL-aks5t6XWMgaJpZM4Uepp6> .

[earlephilhower]

The only way is to do the changes I mentioned above. No hacks readily possible from user code. If you're really stuck on this, a PR is always appreciated. :)

[devyte]

We're a bit overloaded already for 2.5.0, so I'm pushing this back to 2.6.0.