HTTPS Request: SSL Renegotiation on ESP32 fails


i somehow stumbled on this error and i don’t know at which version that started to appear: I Try to use HTTPS with Arduino Framework on ESP32-C3 using the latest available platform (6.4.0). Everything compiles and runs fine, except for when opening an HTTPS connection:

[  3541][E][ssl_client.cpp:37] _handle_error(): [start_ssl_client():273]: (-30592) SSL - A fatal alert message was received from our peer
[  3542][E][WiFiClientSecure.cpp:144] connect(): start_ssl_client: -30592
[  3550][D][HTTPClient.cpp:1163] connect(): failed connect to <domain_omitted>:443
[  3556][W][HTTPClient.cpp:1483] returnError(): error(-1): connection refused
[  3563][D][HTTPClient.cpp:408] disconnect(): tcp is closed

Which indicates something wrong with SSL or networking in general. I then logged the packets that were sent by the ESP32 on my firewall. It shows that the esp32 sends an TLS1.2 Client Hello with Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) as the only available cipher suite. The server responds with a fatal Handshake failure. That is to be expected because it is a security issue and disabled server side.
The same code without modifications worked on an older version of the platform/toolchain/arduino/WebSecure library. I wonder if i am the only persion with this issue though.
Could someone guide me into the right direction to tell the underlying SSL library to offer some real cipher suites instead of doing a renegotion?

Thank you in advance

Does this also occurr with a very minimal skech in the Arduino IDE with the latest Arduino-ESP32 core? If yes, file an issue at instead.

I also looked at the ESP32 code, and nowhere does it explicitly request renegotation (by e.g. calling mbedtls_ssl_renegotiate() or mbedtls_ssl_conf_renegotiation()). The default behavior of mbedTLS should then be to send its ciphersuites along with the TLS_EMPTY_RENEGOTIATION_INFO_SCSV ‘ciphersuite’. If the entire ciphersuite list in the ClientHello is only this one entry though, it seems as if no other ciphersuites / crypto was enabled. This would be very weird and destroy any capabilities of the chip connecting via HTTPS to anything and would be for sure quickly noticed. But there are no open issues about it or recent mentions of handshake failures in Arduino-ESP32.

Arduino IDE (2.2.1) with the latest (stable) Arduino ESP32 Core (2.0.13) does not suffer from this problem and transmits some cipher suites.

Hm. While it is true that even the latest Espressif32 6.4.0 only uses Arduino-ESP32 2.0.11 and not 2.0.13, I don’t see any critical fixes like that in the change log for 2.0.12 or 2.0.13. And the ESP-IDF version stayed the same as “v.4.4.5” too.

In any case, let’s at least even the playing field for PlatformIO and make it use the same core version. Please add

platform_packages =

to the platformio.ini and reupload.

platform_packages =
platform = espressif32
framework = arduino

This is now in the .ini file. Connections are working again. So there seems to be an issue with the current stable version provided by default.
I think that should be analyzed even more because it is a real issue.

When you downgrade the core to 2.0.11 in the Arduino IDE in the board manager, does it fail in the same way PlatformIO did?

2.0.11 is working as well.
2.0.12 also
and 2.0.13 was the latest version in Arduino IDE. So in the Arduino IDE everything seems to work, no matter the version

Well then that shouldn’t be happening-- in PlatformIO, can you use this instead?

platform_packages =

I.e., using the git source instead of the PIO registry source for 2.0.11…

i thought 6.4.0 uses core 2.0.12?

No, it’s 2.0.11 per release notes.

oh, i think i misread your first post about the versions.

platform_packages =
platform = espressif32
framework = arduino

works as well

Ideally there should be no differences between the PIO registry and the git version of things.

Can you please do as follows to get a clean installation agian.

  1. Remove the platform_packages declaration in the platformio.ini again
  2. Close VSCode
  3. Delete C:\Users\<user>\.platformio\.cache folder
  4. Delete all C:\Users\<user>\.platformio\platforms\espressif32* folders
  5. Delete all C:\Users\<user>\.platformio\packages\framework-arduinoespressif32* folders
  6. restart vscode.

This should give you a clean reinstall of the PIO registry version of the 2.0.11. Does the resulting firmware still fail?

Okay now this also works. Seems i had a faulty local install. Weird behaviour though.