ESP8266WebServerSecure BearSSL handshakes failing frequently #6247
Assignees
Labels
waiting for feedback
Waiting on additional info. If it's not received, the issue may be closed.
Comments
|
Please enable full debug and post some output from the failing connects. This is not happening to most people, so without logs (which should give the reason for failure) there's not really anything to go on. |
earlephilhower
added
the
waiting for feedback
|
Sorry about that, I decided to change the debug level from full to SSL before opening the issue for brevity, though admittedly that was counterproductive. Just as a minor update, I am now testing this with the core version below. As soon as I updated the latest git version, and modified the MCVE accordingly, I noticed a huge difference. Looks like I can get pages served in about 2 seconds now! I did notice some of those Debug Messages |
|
Looks good to me on the latest logs. I'd also recommend making sure you're at 160MHz ad 80MHz is pretty marginal in terms of speed and some clients or servers will drop the connection because the handshake takes too long. There have been some BearSSL updates as well, thanks to @s-hadinger , which sped things up, which might be the reason you're doing so well now. I think we can close this for now, and can reopen it should something else pop up later. |
|
I have exactly this issue on a NodeMCU v2 and it's a killer. Saying we should go to 160MHz processor is not the answer; effectively you're saying that TLS is no longer possible on the 80MHz esp8266? |
|
The SSL server was always marginal at 80MHz. I should know, I wrote it back when axtls was the only game in town. :) As always, try with Git head. @s-hadinger did some optimizations to BearSSL EC paths. Also you can reduce the ciphers to the faster but less secure ones, which makes BearSSL faster than axtls. 160MHz makes lots of things better and is not as large a power drain as you might think (the WiFi PA is probably more energy than this tiny core...) |
|
Yes tried the git head and made no difference - but that's because the problem was my own utter incompetence :) Now that I found the fact the TLS fingerprinting mechanism changed and fixed the fingerprint all seems fine, even with an 80MHz part. But thanks for coming back so quickly. Cheers. |
|
Same problem :( I've used HelloServerBearSSL.ino example. Event tried removing mdns - result is the same: |
|
Just to reiterate, please double-check you're running the latest GIT head. There are 10s of KB in tables in flash and, while the It could be a matter of the ciphers being negotiated between the BSSL server and your host. Some, like EC ones, are significantly slower than lower-security RSA codes. As a simple test, try using the IDE menus to select the Tools->SSL->Basic SSL, which removes everything but the simplest RSA codes and be less CPU intensive. |
|
double checked, it's latest git head. decoded: |
|
Put the crash info with MCVE In a new bug, it should work. Looking at the excvaddr it looked like an oom or null pointer will somewhere. |
|
Updated to the latest core. 160MHz and basic ciphers. |
|
That's within the realm of reason. It's 2-3 seconds for me, and I'm talking between a wired client and the ESP8266 server, with the 8266 only a couple meters from the AP. It's a slow, single-core machine, and since it's running everything from SPI flash if there's a cache miss it spends more time waiting for instructions than actually running them... |
|
ah, ok. Thank you very much |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Basic Infos
Platform
Settings in IDE
Problem Description
I am trying to migrate from ESP8266WebServer to ESP8266WebServerSecure, and have been able to successfully connect to a soft-AP created by the ESP via HTTPS. I expected the performance to be noticeably slower compared HTTP, but getting a webpage served up to my smartphone seems like it can take quite a while sometimes. I enabled debug messages to the Serial port, with debug level SSL, and noticed I was seeing this message below very often.
BSSL:_wait_for_handshake: failedThis message shows up somewhat regularly after I connect to the AP and request https://192.168.4.1 on my smartphone's browser. I've tried changing the CPU frequency to 160 MHz, and although it does result in pages being served more often, doesn't seem to impact the handshake process. I noticed this while on 2.5.2, but have installed the latest git version as outlined here.
In the MCVE, the page served by the web server contains javascript which refreshes the page to start another request. The "Served root (millis)" messages help roughly calculate how long it took to serve the page, when compared to the previous value.
Am I misunderstanding the context of the "BSSL:_wait_for_handshake: failed" messages? Based on the debug messages, it appears as if the ESP has occasional moments where the handshakes occur seamlessly.
MCVE Sketch
Debug Messages
The text was updated successfully, but these errors were encountered: