Save SSL Session params (BearSSL) #4796
Comments
|
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 Today that object is cleared and free'd on a Once that's done, it should "just work." |
|
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>
.
|
|
Unfortunately not, @artua . If you issue a |
|
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>
.
|
|
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. :) |
|
We're a bit overloaded already for 2.5.0, so I'm pushing this back to 2.6.0. |
SSL Sessions enable most of the SSL handshake to be skipped when both client and server agree to use them. Add a BearSSLSession class and an optional setting to the SSL client to enable this. Note that SSL sessions are unrelated to HTTP sessions. They are ephemeral and only relate to the SSL parameters, not anything at the HTTP protocol level. Fixes esp8266#4796
Uh oh!
There was an error while loading. Please reload this page.
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.The text was updated successfully, but these errors were encountered: