Disabled TLS secure renegotiation prevents mutual auth from succeeding #9170
Comments
I would guess that would be adding something like 'WiFiClientSecure::setPreserveX509Context(bool)'. We do care only about client though, not server side when WiFiSecureServer is used?
Right, this is because of #9083. I'd say it is really justified, since bearssl funcs apparently try to yield while still using a separate stack. That stack is not within the original task struct, hence the overflow detection trigger. master...mcspr:esp8266-Arduino:bssl/9170-thunk does another dirty hack to stop Maybe not the best solution, but idk what we can do here besides rewriting StackThunk through normal tasks instead of what it is doing right now. |
cont_suspend() wants stack pointer to be within cont.stack and panic()s otherwise esp8266/Arduino#9170 (comment) stack_thunk_yield() func then gets added from the Core side, which should do 'SP store -> yield() -> SP restore' with known stack thunk values esp8266/Arduino@master...mcspr:esp8266-Arduino:bssl/9170-thunk
only rememember a1, yield handles the rest of the registers see esp8266#9170, should no longer crash when using client keys
Basic Infos
Platform
Settings in IDE
Problem Description
It seems that #6165 has broken mutual TLS authentication, with the esp8266 acting as a client, in some scenarios.
I'm attempting to connect to a TLS1.2-enabled apache server from an esp8266 via HTTPS. The server is configured such that it requires that the esp8266 presents a client certificate (ie, I call
WiFiClientSecure.setClientRSACertwith an appropriately-authorized certificate prior to connection). However, I found that requests would fail, even when a similar request, with the same keys, would succeed when attempted from my Windows desktop.I observed the following in my Arduino sketch:
HTTPClient.GETreturning -5, ('connection lost')WiFiClientSecure.getLastSSLErrorreturning 40 ('SSL received fatal alert - Decoding error: extraneous element.')And in my server (apache) logs:
(please forgive my verbosity here - I'm trying to maximise discoverability in case any one else encounters the same issue).
After much troubleshooting, I found this to be a consequence of the linked PR. I am no TLS guru, but I believe that the server will trigger a secure renegotiation once the HTTP headers are received, once it has determined the appropriate vhost to route to. This means it can request the client to authenticate on a per-vhost basis. The linked PR, however, disables renegotiation, and thus the handshake fails. I found this by dumping (and decrypting) the TLS traffic:
As you can see, the esp8266 (
172.17.0.1) sends the HTTP headers, and then sends a warning to the server, stating that renegotiation is not supported. The server then terminates the connection.Reverting #6165 and relevant parts of #6065 appeared to resolve my issue on my install of esp8266 v3.1.2, as the secure renegotiation succeeded, the client is authenticated correctly, and the HTTP request is performed with no problem.
However, in the process of filing this bug, I attempted the same 'dirty hack' on the current git branch (see version hash above), where I was unfortunately met with a stack overflow deep within BearSSL. My TLS/BearSSL skills aren't enough for me to progress this any further.
The decoded stack trace:
MCVE Sketch
Here's a minimised sketch to repro. I don't know if anything specific in my apache setup is triggering this, let me know if you have trouble reproducing and I'll investigate.
To summarise:
I can see the benefit of disabling renegotiation, in terms of resource usage, for the majority of users. However, it seems it is required in some scenarios, such as mine. Would it be possible to enable re-negotiation, as an opt-in feature?
The text was updated successfully, but these errors were encountered: