Skip to content

Save SSL Session params (BearSSL) #4796

Closed
@artua

Description

@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.

Activity

added this to the 2.5.0 milestone on Jun 7, 2018
earlephilhower

earlephilhower commented on Jun 7, 2018

@earlephilhower
Collaborator

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

artua commented on Jun 7, 2018

@artua
Author
earlephilhower

earlephilhower commented on Jun 7, 2018

@earlephilhower
Collaborator

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

artua commented on Jun 7, 2018

@artua
Author
earlephilhower

earlephilhower commented on Jun 8, 2018

@earlephilhower
Collaborator

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

devyte commented on Jul 4, 2018

@devyte
Collaborator

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

modified the milestones: 2.5.0, 2.6.0 on Jul 4, 2018
added a commit that references this issue on Sep 21, 2018
b1b66a4
modified the milestones: 2.6.0, 2.5.0 on Sep 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

Relationships

None yet

    Development

    Participants

    @earlephilhower@artua@devyte

    Issue actions

      Save SSL Session params (BearSSL) · Issue #4796 · esp8266/Arduino