TLS Fingerprint verification keeps failing

[Shazmataz]

Hi all,

I have been having a absolute nightmare trying to get tasmota to use the TLS fingerprint but it ALWAYS fails. My ca certificate common name is the same ip for MQTT host (eg 192.168.1.123) and still not working. I have also disabled most of the other services so definitely not memory related. Fingerprint is also space-separated.

Serial output:
00:00:00 CFG: Loaded from flash at F8, Count 58
00:00:00 Project SOLLamp Sonoff Version 6.5.0.13(sonoff)-2_5_1
00:00:00 WIF: Connecting to AP1 MyNet in mode 11N as SOLLamp-4993...
19:52:42 MQT: Attempting connection...
19:52:42 MQT: Verify TLS fingerprint...
19:52:42 MQT: Failed

I'm using Mosquitto on a Raspberry Pi and using the latest Tasmota release, what am I doing wrong???! I'm sure it's something really basic I'm not doing, literally going crazy!

Thanks! 

[Gerard Sharp]

Hello. I am seeing something similar, trying to stand up a new Shelly under 6.5.0.14

What I note of interest is during the compile I get a warning about BearSSL:

"

<home>/code/Sonoff-Tasmota/sonoff/xdrv_02_mqtt.ino:377:58: warning: 'bool BearSSL::WiFiClientSecure::verify(const char*, const char*)' is deprecated (declared at <home>/.platformio/packages/framework-arduinoespressif8266/libraries/ESP8266WiFi/src/WiFiClientSecureBearSSL.h:180): This is deprecated AxTLS API, check https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/src/WiFiClientSecure.h#L25-L99 [-Wdeprecated-declarations]
if (EspClient.verify(fingerprint1, Settings.mqtt_host)) {"

"

The link isn't interesting, but the BearSSL Docs at https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/bearssl-client-secure-class.html ARE interesting; reading there suggests that BearSSL has changed the way TLS works on ESP8266 projects which include it. Hopefully for the better.

It is possible that in moving arduino core to 2.5.2, Tasmota has picked up BearSSL and hasn't made the corresponding changes to certificates and fingerprints, which means the verfication fails?

[Piotr Antczak]

Have a look here:  https://github.com/arendst/Sonoff-Tasmota/commit/3d08514060fcac3b2c1666884d42a3acf4e8078c#diff-237285c047dad808f73698c139144e1a

Try to contact Jason2866 on Discord.

--
You received this message because you are subscribed to the Google Groups "SonoffUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/30da7252-cfd5-42b8-87c7-13ae6a7297e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Piotr Antczak

[Gerard Sharp]

Okay, I have performed an experiment.

I have Sonoff-Tasmota 6.5.0.14 compiling under PlatformIO under Linux, and it worked: I have my Shelly connecting to the MQTTS server, posting to topics and seeing messages that it is subscribed to.

I edited xdrv_02_mqtt.ino and made a few changes:

* added #include "BearSSLHelpers.h"

* replaced all "WiFiClientSecure EspClient" with "BearSSL::WifiClientSecure EspClient" (i.e. made the class explicit)

* in function MqttCheckTls, removed the calls to "EspClient.verify" that were AFTER the EspClient.connect() line, and replaced them with a call to EspClient.SetFingerprint(fingerprint1); BEFORE the call to EspClientconnect().

* instead of the verify code, just set result=true;

And it worked. my Shelly is talking to the MQTT server.

This hack works because the previous code (2018 and earlier) assumed the server was good and you have to verify manually; while BearSSL assumes the server is bad and you must provide validation BEFORE you connect.

This is a terrible, terrible hack, because it only offers fingerprint1. And because it almost certainly doesn't handle a server that doesn't match the certificate! (so when my 14yo neighbour starts spoofing my SSID for the lolz, my hack will probably not fail as intended)

In theory BearSSL offers many more options, better than just SHA1 Fingerprints; like importing an X.509 chain of trust, but that will require more code to implement.

So yeah, I made a hack and did a thing.

[Stephan Hadinger]

You may want to take a look at the PR I just released for AWS IoT support, which relies on TLS 1.2 and client certificate.

I'm using BearSSL and changed the standard Arduino implementation to save a lot of code and memory. Basically I only support one cipher: BR_TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Depending on the server you want to connect to, it may work or not.

I changed the Fingerprint implementation to add two options: 1/ learn on first connection, if you set fingerprint to all-zeros, it will learn it during first connection (this is easy and generally acceptable in terms of security), 2/ accept any fingerprint (set to all 0xFF). Also keep in mind I'm doing a fingerprint of the public key, not the server certificate. This is more robust if there is a certificate renewal, there is a good chance the public key does not change.

https://github.com/arendst/Sonoff-Tasmota/pull/5923

[Shazmataz]

Hi Stephen!

Looking at your code your pr is amazing! I was just wondering how I use the fingerprint learning with my own server? Do I just activate AwS support?

Thanks in advance!

[Stephan Hadinger]

Hi,

I completed the TLS page with detailed instructions: https://github.com/arendst/Sonoff-Tasmota/wiki/TLS

If you are using Letsencrypt certificate, you just need to enable both USE_MQTT_TLS and USE_MQTT_TLS_CA_CERT.

If you use your own certificates, or self-signed, then you need to enable Fingerprint auto-learning with:

MqttFingerprint1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Hope this helps,

Stephan 

[Shazmataz]

Hi!

That's great, thanks very much for your help and hard work!

Shaz

[Shazmataz]

Hi

Sorry me again! I'm using a self-signed certificate and I keep getting a TLS connection error: 296 (not 298).

I've tried varying settings and either get rc -2. Retry in 10 sec or rc -4. Retry in 10 sec!

What am I doing wrong?

Thanks

On Sunday, 30 June 2019 18:07:54 UTC+1, Stephan Hadinger wrote:

[Stephan Hadinger]

Hi,

I just want to make sure that you did NOT enable USE_MQTT_AWS_IOT, it is not useful and will add unnecessary constraints.

All errors above 256 indicate a server error, to know the code you need to substract 256. So error 296 is actually SSL Server Error #40, which means HANDSHAKE_FAILURE. This is probably due to the fact that your server does not support TLS 1.2 or does not support the cipher TLS_RSA_WITH_AES_128_GCM_SHA256 (which is unlikely).

What server software are you using?

Le dimanche 30 juin 2019 21:55:11 UTC+2, Shazmataz a écrit :

Hi

[Shazmataz]

Hi

Thanks for replying, USE_MQTT_AWS_IOT is disabled. I'm using Mosquitto, NginX and openssl on a Pi. Before trying to migrate to Tasmota I was using my own esp8266 solution with httpSecure but I've had to create a new certificate since, which is probably where I am making the mistake. If I'm using fingerprint verification, I don't need separate private keys right?

Once again many thanks!

[Stephan Hadinger]

You need to make sure your server has the private key and the corresponding certificate (self-signed is ok). Also make sure the certificate is RSA, max 2048 bits and uses SHA256 signing.

You can connect to your server with openssl to check the certificate (don't know the command by heart but you should find it easily).

Le dimanche 30 juin 2019 23:10:45 UTC+2, Shazmataz a écrit :

Hi

[Shazmataz]

Great I'll check it out. Thanks very much for your help. I really appreciate it!

[Shazmataz]

genius! Have you got a donation page?

Thank you very much!

On Sunday, 30 June 2019 22:19:58 UTC+1, Stephan Hadinger wrote:

[Shazmataz]

To anyone that is still having issues I managed to work out (with the help of Steven and his new coding) whayt my problem was. Before Steven's code I was following a number of different guides of how to create self-signed certificates and tried to use the fingerprint verification to get the fingerprint of my server I was using various commands via openssl and always getting the same fingerprint, however I kept reading that TLS 1.2 was not compatible so I changed it to 1.1 although I was still getting the same fingerprint. It wasn't until I used Steven's auto fingerprint fetching method and setting the server back to TLS 1.2 that I realised that the fingerprint that I was getting was the wrong fingerprint

So if you are having the same problem set your server to support TLS 1.2 and then use the automatic fingerprint fetching as documented by Steven. Then if you use something like Termite to send commands to the device, you can find out the correct fingerprint for your certificate!

Hope that helps