-
Notifications
You must be signed in to change notification settings - Fork 13.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SSL Session capability to speed reconnections #5160
Conversation
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
Here's how much time it saves on an 80MHz core. It's dramatic, when sessions are supported by the server!
|
Sounds promising! In the issue this fixes it says
I don't understand most of the C code but it looks like this isn't (can't be?) supported yet? My real life use-case is exactly that: wake-up, WiFi, NTP, 1 TLS request, processing, deep sleep 30min. |
I'm not too familiar with deep sleep modes on the ESP. Do you lose RAM contents? If so, then if you can find enough space for However, in 30 minutes a heavily used SSL server may not have your session stored anymore. Things will still work, the session will be ignored and you will do a full handshake. If you own the SSL server, you can try and expand the cache and TTL values somehow to help ensure any session token lasts >30 minutes, probably. |
@earlephilhower a deepSleep is essentially a reset on the ESP, so yes: you lose everything. |
Doing a flash overwrite every 30 minutes seems like a dangerous things to do if you want years of lifetime in the field. :( |
I was assuming a write only on establishing a new handshake, and no write every time the session is reused. Maybe my thinking is wrong there, and the state changes often? |
It's mostly identical, but that depends on the server. It is possible to cause SSL renegotiation on a connection at any time, so you may have the same encrypted_state or may not. I suppose a memcmp() would be prudent on the existing stored state before trying to rewrite it. FWIW in the example code the session data is constant for all connections in a series, but that's three connections transferring 10s of bytes in a matter of 1-2 seconds, so not exactly a guarantee. |
Hi @earlephilhower
|
Github was having a bad day yesterday, so if this is a log from then I'd just re-try it. If the first "connecting from unitialized session" doesn't work (that's the same as w/o session) then there won't be a session for the second or third to try. It could also be a momentary network hiccup in the 8266. The other cause might be GitHub changing their SSL certs yet again. I think we've updated hardcoded certs three times this year already. |
It's from today.
|
I tested it on my system just now and it connected with sessions fine (although it seems the github api returns a "403 Forbidden"...but SSL connects and HTTP is processed to get this error). Are you running a clean git head? |
I successfully incorporated sessions in my main project.
|
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 #4796