Description
This is a follow-up to #4738 (comment)
Claim
I observed that BearSSL in standard configuration takes more than twice as long for a handshake as axTLS.
Basic Infos
- This issue complies with the issue POLICY doc.
- I have read the documentation at readthedocs and the issue is not addressed there.
- I have tested that the issue is present in current master branch (aka latest git).
- I have searched the issue tracker for a similar issue.
- If there is a stack dump, I have decoded it.
- I have filled out all fields below.
Platform
- Hardware: WeMos D1 Mini Pro
- Core Version: 2.4.2
- Development Env: Arduino IDE
- Operating System: macOS
Sample sketch
The below sketch is inspired by what @artua presented at #4738 but it's much simpler. I feel that when just starting out measuring / comparing performance you shouldn't collect too much data at once as you might not see the wood for the trees. Once you identify a suspect you then adjust the rig accordingly and collect more data around the suspected culprit.
The program establishes a connection to a SSL/TLS protected host 50 times with a delay of 1.5s. For every attempt it reports total failure/success count, accumulated handshake time, average handshake time and free heap at the end. No server certificates or fingerprints are verified!
Around line 40 you define whether to use BearSSL (with setInsecure()) or axTLS.
#include <ESP8266WiFi.h>
#define HOST "thingpulse.com"
#define PORT 443
#define WIFI_SSID "ssid"
#define WIFI_PWD "password"
const char* ssid = WIFI_SSID;
const char* password = WIFI_PWD;
int numberOfSamples = 50;
int totalCounter = 0;
int failCounter = 0;
uint64_t totalDuration = 0;
void setup () {
Serial.begin(115200);
Serial.println("");
WiFi.begin(ssid, password);
Serial.print("Connecting to Wifi");
while (WiFi.status() != WL_CONNECTED) {
delay(300);
Serial.print(".");
}
Serial.println("done.");
}
void loop() {
if (totalCounter < numberOfSamples) {
bool success = connectToHost();
delay(1500);
}
}
bool connectToHost() {
uint64_t startTime = millis();
// BearSSL::WiFiClientSecure client;
// client.setInsecure();
WiFiClientSecure client;
boolean success = false;
totalCounter++;
if (client.connect(HOST, PORT)) {
// Serial.printf("Connection to %s success.\n", HOST);
success = true;
} else {
failCounter++;
// Serial.printf("Connection to %s failed.\n", HOST);
}
client.flush(); // not actually needed
client.stop();
totalDuration += millis() - startTime;
Serial.printf("Failed: %d, Total: %d (%f %%), Total Dur: %d, Avg. Dur: %f, Heap: %d\n",
failCounter,
totalCounter,
(100.0 * failCounter / totalCounter),
totalDuration,
1.0 * totalDuration / totalCounter,
ESP.getFreeHeap());
return success;
}Test results
I ran the above sketch with all combinations of BearSSL/axTLS, lwIP v2 lower memory/higher bandwidth and 80/160MHz on core 2.4.2. So, this makes 2^3 * 50 samples.
The summary is as follows:
0 connection failures. That's remarkable as this whole endeavour started out with this issue https://stackoverflow.com/q/52143894.
BearSSL
- lwIP v2 lower memory, 80 MHz: ~860ms
- lwIP v2 higher bandwidth, 80 MHz: ~845ms
- lwIP v2 lower memory, 160 MHz: ~510ms
- lwIP v2 higher bandwidth, 160 MHz: ~500ms
axTLS
- lwIP v2 lower memory, 80 MHz: ~360ms
- lwIP v2 higher bandwidth, 80 MHz: ~350ms
- lwIP v2 lower memory, 160 MHz: ~250ms
- lwIP v2 higher bandwidth, 160 MHz: ~240ms
-> BearSSL takes more than twice as long
-> As expected higher bandwidth has close to zero impact as only a socket connection with handshake was established. No resources were loaded from the host.
The detailed result is in the below PDF.
BearSSL-vs-axTLS.pdf
Over at #4738 @earlephilhower stated that
BearSSL often negotiates a more secure but slower running cypher... limiting the receiving end's connection capabilities in your SSL configuration
I would first have to look into that. Not familiar with SSL config yet.