SSL Error when trying to access the server with Dialogflow Webhook

[michaelmalice]

I'm trying to use google assistant turn my computer on through an ESP32. I have been running a regular http server that IFTTT hits with Webhooks at a certain address (/power) and it turns on the pin. Simple. I'm now trying to cut out the IFTTT middle man and go directly from google to my ESP32 as a dialogflow action. Dialogflow requires https, so here we are.

I can hit my ESP32 on a web browser and it shows the certificate as being fine and valid ( I copied one I already had and converted it using the steps in your script to get them in the right format ) but when I try from Dialogflow I get an SSL error on the ESP32.

Setting up WiFi ..Connected. IP=10.0.0.21 Starting server... Server ready. 790695 HTTPSServer->debug: [-->] New connection. Socket fid is: 0x37 792534 HTTPSServer->debug: [ERR] SSL_accept failed. Aborting handshake. 792537 HTTPSServer->debug: [<--] Connection has been closed. fid = 0x37 792538 HTTPSServer->debug: [ ] Free headers

Any help on this would be greatly appreciated. Thank you for all the work you've done.

[fhessel]

Most likely, if an error occurs in SSL_accept, it's because client and server are not able to negotiate encryption parameters for the TLS connection. That would well fit your observation that one client (the browser) is able to connect, while the other (dialogflow) is not.

I created the script in this Gist to check which cipher suites are actually available on my ESP32 (at least as far as my OpenSSL implementation supports them), and got the following results:

ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA256
AES128-SHA
AES256-SHA

Are you somehow able to capture the TLS Client Hello message from Dialogflow via Wireshark or a similar tool to verify that Dialogflow is using one of the supported ciphers? If that's not the case, we can investigate this further.

[fhessel]

I just remember to have read something about Dialogflow to have a connection timeout of 5 seconds.

If that's the case, all DH_ ciphers are most probably unusable as well:

ECDHE-RSA-AES128-GCM-SHA256... OK (took 1598ms)
ECDHE-RSA-AES256-GCM-SHA384... OK (took 1486ms) ← prefered by ESP32
DHE-RSA-AES128-GCM-SHA256... OK (took 4915ms)
DHE-RSA-AES256-GCM-SHA384... OK (took 4946ms)
ECDHE-RSA-AES128-SHA256... OK (took 1451ms)
ECDHE-RSA-AES128-SHA... OK (took 1459ms)
ECDHE-RSA-AES256-SHA384... OK (took 1455ms)
ECDHE-RSA-AES256-SHA... OK (took 1485ms)
DHE-RSA-AES128-SHA256... OK (took 4943ms)
DHE-RSA-AES128-SHA... OK (took 4953ms)
DHE-RSA-AES256-SHA256... OK (took 4937ms)
DHE-RSA-AES256-SHA... OK (took 4926ms)
AES128-GCM-SHA256... OK (took 245ms)
AES256-GCM-SHA384... OK (took 257ms)
AES128-SHA256... OK (took 248ms)
AES256-SHA256... OK (took 251ms)
AES128-SHA... OK (took 250ms)
AES256-SHA... OK (took 249ms)

That's for local traffic only. Add some network delay, and you will get Dialogflow to terminate the connection during the handshake due to timeout, which will also lead to a failure in SSL_accept.

[michaelmalice]

Thank you for your quick reply. I'm trying to find a way to sniff the packets in my network so I will let you know when I find out the cipher that is being used. If it can be done in the 5 second window then I will see what next steps can be done. Thanks again!

[fhessel]

If you need any help regarding the packet sniffing, just let me know. It's not that easy at first, but becomes very handy for development once you know how to do it.

In my opinion, the most viable options are:

• Preferable and most convenient: Check if your router provides packet logs (some have that available in a specific "support section")
• Setup your notebook as an "hotspot"/access point and let the esp connect to it (however, port forwarding for external access might be a bit tricky if you cannot simply bridge both interfaces)
• Setup a reverse proxy webserver on your computer and let Dialogflow connect to that proxy. The cipher list that your computer will see should be the same that Dialogflow will offer to the ESP.
• Use ARP spoofing to redirect the ESPs traffic through your computer (feasibility depends on the network layout, do it only in you own network for legal reasons)

[fhessel]

Is there any progress on this or do you still need support? Otherwise I'd close the issue as it's not really actionable for me.