SSL/TLS handshake issue

[GothAck]

Anyone from Espressif care to chime in here?

[tshup]

i did 2 things to fix this problem,
using espconn_secure_set_size(3,8192),
and disabled all other server and client connections (my little web server). so that only a single SSL connection is active (in my case to a local mosquitto server with some self signed 2048 bit key)

[Nico]

I have the same issue. But I´m using AT-Comands.

I have tested:

AT+CIPSTART="SSL","de.yahoo.com",443<CR><LF>
AT+CIPSTART="SSL","smtp.1und1.de",465<CR><LF>
AT+CIPSTART="SSL","74.125.136.100",465<CR><LF> (smtp.google.com)

But everey time I become the answer:
<CR><LF>ERROR<CR><LF>
CLOSED<CR><LF>

when I connecting to a server and look at the handshake with wireshark, then the esp8266 send after the SSL Hello from the Server, a SSL Alert to the Server with the Description "Handshake Error".

The SSL works only fine, if I use my own SSL-Server without certification.

Changing the CIPSSLSIZE or the CIPMUX makes no different.

[oz.edri]

I have the same issue. But I´m using AT-Comands.

I have tested:

AT+CIPSTART="SSL","de.yahoo.com",443<CR><LF>
AT+CIPSTART="SSL","smtp.1und1.de",465<CR><LF>
AT+CIPSTART="SSL","74.125.136.100",465<CR><LF> (smtp.google.com)

But everey time I become the answer:
<CR><LF>ERROR<CR><LF>
CLOSED<CR><LF>

when I connecting to a server and look at the handshake with wireshark, then the esp8266 send after the SSL Hello from the Server, a SSL Alert to the Server with the Description "Handshake Error".

The SSL works only fine, if I use my own SSL-Server without certification.

Changing the CIPSSLSIZE or the CIPMUX makes no different.

Did you manage to solve this issue?
I'm having the same issue when trying to connect to Firebase (also by Google) with the AT+CIPSTART="SSL" command.
That said, I'm able to connect to other SSL sites with that command, including google.com

[joezop]

I would not expect enabling CA verification would help if it does not work with it disabled.

[ESP_Frank]

Hi,

Perhaps someone else already discovered the reason behind the ESP8266 SSL Handshake Failure, but I found out that ESP8266 sends an initial Random during Client Hello with UNIX Timestamp 00000000 (=Jan 1, 1970 01:00:00.000000000). This is outside the web server certificate's time frame and may be a reason for the web server to reject the connection.

I am using an ESP8266 containing:

AT version:1.7.5.0(Oct 9 2021 09:26:04)
SDK version:3.0.5(b29dcd3)
compile time:Oct 15 2021 18:05:38
Bin version(Wroom 02):1.7.5

Before sending AT+CIPSTART="SSL","servername",443 I did configure SNTP using AT+CIPSNTPCFG=1,1,"pool.ntp.org" and issued a successful SNTP request with AT+CIPSNTPTIME?. But still the time info in the Random remains 0. See wireshark extract below:

Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 47
Version: TLS 1.1 (0x0302)
Random: 000000006606ced024c458f0afad29b242403955b02a121fd48d0fc83c452f44
GMT Unix Time: (0)Jan 1, 1970 01:00:00.000000000
Random Bytes: 6606ced024c458f0afad29b242403955b02a121fd48d0fc83c452f44
Session ID Length: 0
Cipher Suites Length: 8
Cipher Suites (4 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

The (Apache) webserver is allowing TLSv1.1, but responds with:

Transport Layer Security
TLSv1.1 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.1 (0x0302)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)

To test what happens if the Apache server does NOT accept TLSv1.1 I temporarily modified the server's SSL configuration. Then it responds as follows:

Transport Layer Security
TLSv1.1 Record Layer: Alert (Level: Fatal, Description: Protocol Version)
Content Type: Alert (21)
Version: TLS 1.1 (0x0302)
Length: 2
Alert Message
Level: Fatal (2)
Description: Protocol Version (70)

So it indicates reject because of the used TLS protocol version.

The server also accepts ciphers TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA, so this is probably not the reason for handshake failure.

So I have the strong impression that the wrong time stamp is the reason for the failed SSL connections. Any idea how this can be solved?
Thanks!