HTTPSConnect Connection Failed

[msbeck]

Basic Infos

Hardware

Hardware: Wemos D1 mini

Description

Running HTTPSConnect and successfully connecting to api.github. Switch the paths to point towards my own server and connections fail. I get a "connection failed" message.

How do I get specific failure codes to understand better why it's not working?

I don't have direct access to the server I'm trying to hit, so for fun, I spun up a flask server on a pi to try to gather more data.

My pi Flask server is not happy about what is coming from the pi. It's returning a code 400 and saying its getting a bad HTTP/0.9 request.

Full response here: https://gist.github.com/maurbeck/39b0217df27396aa120db1f2d46ddf7b

[msbeck]

Anybody know what TLS/SSL version this library uses?

[gjt211]

Hi maurbeck.
I am having other issues with TLS/SSL, but from what I (think) worked out today, I believe it must be TLSv1.1, with RC4-SHA. I added RC4-SHA and removed !RC4 in my apache ciphers list configuration which got me going, but now my site's security only rates B- rather than an A because RC4 is not considered very secure. From my searching through the issues here, it seems like the TLS is using the code from axTLS which only supports TLSv1.1
Hope that helps you.

[bebo-dot-dev]

axTLS has been updated to v2 which has support for TLS1.2. See #2537
This change is not in the latest 'official' 2.3.0 release however because it's a change that was implemented some time after when 2.3.0 was released on 23/06 so if you wanted to give this a try, you'd need to directly use the current git code.

[msbeck]

Great news. I'll try that out, thanks.

Would a typical server be able to send an intelligible error code for this? It was quite a pain to debug what was going on without any way of knowing why the connection failed and I didnt see a way of exposing an error code in the library.

[bebo-dot-dev]

If you're trying to workout what goes wrong at TLS handshake time, the thing you're probably interested in is the int response from an ssl_handshake_status function call. The official axTLS docs are here: http://axtls.sourceforge.net/dox/group__c__api.html

Inside the WiFiClientSecure class this is called at connect time inside WiFiClientSecure::_connectSSL but unfortunately the value isn't surfaced out when something goes wrong. See here:

Arduino/libraries/ESP8266WiFi/src/WiFiClientSecure.cpp

Line 319 in 4897e00

auto status = ssl_handshake_status(*_ssl);

At the moment it's setup so that 1 == success and 0 == fail. You could change this locally so a failure value does get returned back in the connect call and that might give you what you need.

If that works as expected you could submit a pull request as a potential improvement :)

[msbeck]

I have uninstalled the stable ESP 2.3.0 and installed 2.3.0-rc2. This did not solve my problem, so I'm wondering if that was my issue in the first place.

So now I'm moving on to trying to return some information in _connectSSL. I see that the status is returned as type auto. It's simply checked against SSL_OK.

What lib is ssl_handshake_status() from?

[bebo-dot-dev]

2.3.0 rc2 was a pre-release version of 2.3.0

If you're aiming for TLS1.2 support in axTLS then 2.3.0.anyVersion just won't do it. At all. If TLS1.2 is what you want, you need to use the git code as I previously mentioned.

[msbeck]

Oh, I see. I thought that the git code itself was accessible from the staging directory.

I'll go back and look at how to do what you've suggested once again.

[msbeck]

Ok, can you hold my hand a little while longer please?

I've pulled the code from git into the esp8266com dir according to your link. Then I downloaded the binary tools by running get.py and restarting Arduino.

I tried running again and got the same issue as before where the connection fails. Do I need to switch to using esp8266com rather than the standard one in some manner or something? I don't understand what is next.

[msbeck]

I uninstalled the esp8266 2.3.0 lib again and think that I should be finding a way to add the esp8266com files to my boards. I'm wondering if I should just copy the contents of this over top of the existing esp8266 2.3.0 lib contents.

Trying that next.

[msbeck]

Did that. Did not work. Wondering if I should try to use DEBUGV to log that response so that I can understand what's going on. Should I try using DEBUGV in such a manner? I wouldn't know how to begin down that journey...

[bebo-dot-dev]

Are you developing your stuff with the arduino IDE / trying to get this projects' cloned git code working in the arduino IDE by any chance?

[msbeck]

Yes, I'm using the Arduino IDE. Is that possible?

[bebo-dot-dev]

Yes I'm sure it's possible but I'm afraid I won't be able to help you determine if it's setup correctly with cloned github code because I gave up on it long ago myself.

[davisonja]

@maurbeck Still having trouble making the git clone work? :)

[eiannone]

Hi @maurbeck , I'm having your same issue. When trying to connect with WiFiClientSecure, ssl_handshake_status() function returns -1 (SSL_NOT_OK)
I'm using Arduino IDE with latest esp8266 library cloned from github, and Wemos D1 mini hardware.
Did you manage to solve the problem?

[msbeck]

Sorry guys, I have up on trying to make it work shortly before I ended the project that needed it.

The solution I was eyeing though was to have a pi relay the info with the proper SSL stuff. Won't work for many projects though :/

[eiannone]

Hi, after some investigation I found that the issue is due to lack of ciphers compatibility between ESP8266 and the server.
ESP8266 uses the axTLS library (http://axtls.sourceforge.net/), built in from Expressif SDK, which supports only the following ciphers:
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

My server instead supports only TLS_ECDHE_RSA_* and TLS_DHE_RSA_* ciphers, so they cannot complete the handshake phase.

[igrr]

@eiannone we don't use the library which comes from the Espressif SDK, instead this port is used:
https://github.com/igrr/axtls-8266
You're correct about the list of supported cipher suites though :)

[eiannone]

I didn't know that @igrr , thank you for pointing it out!

[devyte]

BearSSL is merged in #4273 , with alternate BearSSL::WiFi* classes. Although axtls-based classes are still available and even the default, they are planned for deprecation and then retirement, hence won't be fixed. Any issues with BearSSL-based classes should be reported in new issues.
Closing.