WiFiServerSecure: Cache SSL sessions #7774
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WiFiClientSecure::setSession
allows users to use a feature in BearSSL to cache the SSL session to a server.BearSSL also allows caching SSL session on the server side, therefore I've created the method
WiFiServerSecure::setCache
to allow the user to setup a cache allowing BearSSL to resume the SSL sessions of client and greatly shorten the length of TLS handshakes.Here are the steps that I have followed when implementing this feature:
ESP8266WiFi
libraryESP8266WiFi
librarykeywords.txt
fileESP8266WiFi
library (I've chosen the BearSSL_Server example)ESP8266WebServer
library (I've chosen the HelloServerBearSSL example)If you want to test this feature, I encourage you to use these examples and to enable and disable the cache to see the performance improvements. In order to reset the server's cache, you simply have to reset the microcontroller.
Testing the examples
Here's a ruby script that I've written to test the performance improvements that this PR is bringing. It does 100 requests using a new SSL session each time and 100 more using the same session.
Results
I've used this script to test the BearSSL_Server and HelloServerBearSSL examples before, after this PR without the cache activated and after this PR with the cache activated. For BearSSL_Server, I did the test once with the RSA key and another time with the EC key.
BearSSL_Server with the RSA key
Before the PR
After the PR without caching
After the PR with caching
Summary
The improvement ratio is the time of
Don't reuse the session
over the time ofReuse the session
.BearSSL_Server with the EC key
Before the PR
After the PR without caching
After the PR with caching
Summary
The improvement ratio is the time of
Don't reuse the session
over the time ofReuse the session
.HelloServerBearSSL
Before the PR
After the PR without caching
After the PR with caching
Summary
The improvement ratio is the time of
Don't reuse the session
over the time ofReuse the session
.Analysis
Those numbers show that this PR makes the HTTPS requests about 25x faster with an RSA key and 6x with an EC key when caching is enabled. When caching isn't enabled, this PR doesn't seem to negatively affect performance at all.
We can see that BearSSL_Server is faster than HelloServerBearSSL and its improvement is greater, because this PR only improves the TLS handshake, so the longer the server takes to parse the request and create a response, the less improvement there is and HelloServerBearSSL implements a web server which is slower than BearSSL_Server that answers all requests with the same response without parsing them.
It is to be noted that, in the script that reuses the session, the time of the first request of the session isn't counted because this PR doesn't improve it.
Testing the TLS handshake improvement
The previous test was testing the speed improvement for the full HTTP request, but this PR should only improves the TLS handshake.
In order to see it I've tested the BearSSL_Server with an RSA and an EC key using Firefox's network timing analyzer.
This test is a little less rigourous, because I didn't do it 100 times like the others, but it allows us to see the improvement for each part of the request.
RSA key
Before the PR
After the PR without caching
After the PR with caching
First request:
All subsequent requests:
Summary
The improvement is the measure before the PR over the current measure.
EC key
Before the PR
After the PR without caching
After the PR with caching
First request:
All subsequent requests:
Summary
The improvement is the measure before the PR over the current measure.
Analysis
These numbers show the same thing as the previous tests: this PR greatly improves the speed of cached requests and doesn't have any noticeable downside.
However, this test shows clearly shows how much the TLS handshake is a bottleneck without this PR and how much it's improved when the server caches the client's sessions.
Somehow it also slightly improves the waiting time for the server response. I don't think it means that the server decrypts the request faster or processes it faster in any way. I simply think that this is because when resuming cached sessions the client ends the handshake instead of the server. This means that the client can start sending the application data at the same time as it sends the TLS record to end the handshake. This would therefore reduce the time the client has to wait for the server response.
You can see this at page 35 and 36 of the TLS 1.2 standard:
Conclusion
This PR doesn't seem to have any negative performance impact, only positive ones. Once enabled by the user, it will increase performance of cached sessions by 20 to 25 times depending the type of encryption used. The slower the encryption is, the more this feature will boost performances. However, users need to be well aware that the TLS client they're using also needs to cache the session in order to experiment this performance boost. This is why it was clearly mentionned in the documentation.