Tasmota: What type of SSL/TLS support is included in Sonoff-Tasmota?

[KonstantinMastak]

I want to enable TLS support, but I see that I can only set MQTT_FINGERPRINT which is, as far as I understand, a fingerprint of server (public) certificate.

I searched through sources of Tasmota and pubsubclient and I can't find anything like these:

espClient.setCertificate(client_bin_crt, client_bin_crt_len);
espClient.setPrivateKey(client_bin_key, client_bin_key_len);

Does it mean that server cert fingerprint check is the only part which is implemented by now, and I can't use real client-side certs at this time?

[arendst]

Correct. If you know of an esp8266 SSL/TLS implementation using only 470MB with your wishes just let me know.

[KonstantinMastak]

Thank you for your answer! I just came accross this article:

https://hackaday.io/project/12482-garage-door-opener/log/45617-connecting-the-esp8266-with-tls

It seems that full (more or less) TLS implementation can be achieved, if we:

1) Upload client cert file to ESP flash. Article suggests using ESP8266FS tool for Arduino IDE for this.
2) Open and load these files into memory using SPIFFS
3) Use wifiClient.loadCertificate and then wifiClient.loadPrivateKey
4) Then do what you already do - call wifiClient.verify, etc.

However, it is not clear for me if these steps will result in client->server authentification. Maybe, not.

[SpiraMirabilis]

if you have a server on permises you can use stunnel and have the server/computer handle SSL and proxy traffic to the ESP8266

[davidelang]

@KonstantinMastak the example that you point to is also just using fingerprinting rather than full CA validation. Given the small amount of space left on the devices, I don't see how we could possibly afford to include the CA certs needed to validate some random cert we run into. So the best that we could do is to allow certs signed by a specific CA.

My day job is computer security (almost 20 years protecting financial data, including almost 2000 banks and credit unions), and just validating that it's a valid cert isn't enough, you also need to validate that it's a cert you are supposed to accept, and the fingerprint of the cert is a very good way to do that. So it's not clear to me that there is any significant advantage to changing to full validation.

running stunnel or a reverse proxy is a far better approach.

Please re-open this if you do find a way to do full validation in a small space

[khcnz]

And you don't want to have to deal with things like cert revocation, or for example REQUIRING external network access to NTP to get the current date to check the cert is in its validity period. Thumbprint is a pretty accepted way to do business...

[KonstantinMastak]

Thank you for all your answers! This really makes sense. I'll go on with fingerprinting.

[wiktorschmidt]

Just wanted to share this here: https://github.com/copercini/esp8266-aws_iot

Also a related discussion:
https://github.com/aws/aws-iot-device-sdk-embedded-C/issues/7

[SpiraMirabilis]

If you'd like to be extra careful you can use a server to monitor for
revocations and then push a HMAC signed "revocation event" to the ESP.

On Mar 19, 2017 5:28 PM, "KonstantinMastak" [e-mail]
wrote:

Thank you for all your answers! This really makes sense. I'll go on with
fingerprinting.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-287657047,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gEfSiwwAMHMjWYZCfQy41ICUry1cks5rnboCgaJpZM4MTGq4
.

[Sunrise17]

@KonstantinMastak, Have you ever solved or to formulate fingerprint instead uploading AWS Certificates (cert.pem, private.key, CA.pem) to Tasmota?

[KonstantinMastak]

@Sunrize17, Sorry, but I decided not to dig into this topic anymore. I do
not critically need SSL right no, so I use Tasmota without SSL at all. I
think that due to memory limitations implementing real SSL is impossible
for ESP.

2017-10-11 0:26 GMT+03:00 Sunrise17 [e-mail]:

@KonstantinMastak https://github.com/konstantinmastak, Have you ever
solved or to formulate fingerprint instead uploading AWS Certificates
(cert.pem, private.key, CA.pem) to Tasmota?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-335613044,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYvBky_5qFCHlSCayL8_FbbBiymOPZGNks5sq-DogaJpZM4MTGq4
.

[Sunrise17]

@KonstantinMastak, Is it possible to use Tasmota with AWS IoT?

[KonstantinMastak]

I don't know. I never used AWS IoT.

2017-10-12 14:13 GMT+03:00 Sunrise17 [e-mail]:

@KonstantinMastak https://github.com/konstantinmastak, Is it possible
to use Tasmota with AWS IoT?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-336096975,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYvBk7rjlAFCSM9JVgK-UdzrkLOvMx7uks5srfQ7gaJpZM4MTGq4
.

[ChaoticEnigma]

I'm a little confused by the discussion here. The original question was whether it is supported to add a certificate and private key to the firmware for MQTT TLS (presumably for authentication on the server side). And then the subject changed to CA certificate validation?

It seems the answer to the original question is currently no. But, it seems that the ESP8266WiFi library supports this, so I don't see why it couldn't be implemented. A DER private key (2048-bit) and cert should be <3KiB.

Since a private key is not currently included with the firmware, what is used for the SSL connection? Is a key generated in memory at startup?

And yes, implementing "real" CA validation may be impossible, but I think a fingerprint for the server cert is enough for the time being. From a security standpoint, I'm more worried about unauthorized devices connecting to my broker than a man-in-the-middle attack on a client device.

[SpiraMirabilis]

The problem is that you have to have the fullchain of the CA certs to
vaidate most certificates, and this is a big issue with the space available
on the serial flash. So a work around is to validate it based on just the
fingerprint, which is not very large at all. But this is not compliant. It
might be good enough, but you'd never know about revocations, etc. What I'd
recommend if for project or org reasons you had to have something that was
more compliant then you could use a HMAC/fingerprint for a VPS/docker based
simple web service -- the ESP would send an API request to the web service
which would validate it and then sign the response with the server's
private HMAC key so you know definitively that the message was sent by your
server (so long as the private key wasnt stolen.) The ESP could potentially
put the fingerprint into a banned list while updating it to a new one, or
similar.

On Sun, Nov 19, 2017 at 10:29 AM, Charlie Waters [e-mail]
wrote:

I'm a little confused by the discussion here. The original question was
whether it is supported to add a certificate and private key to the
firmware for MQTT TLS (presumably for authentication on the server side).
And then the subject changed to CA certificate validation?

It seems the answer to the original question is currently no. But, it
seems that the ESP8266WiFi library supports this, so I don't see why it
couldn't be implemented. A DER private key (2048-bit) and cert should be
<3KiB.

Since a private key is not currently included with the firmware, what is
used for the SSL connection? Is a key generated in memory at startup?

And yes, implementing "real" CA validation may be impossible, but I think
a fingerprint for the server cert is enough for the time being. From a
security standpoint, I'm more worried about unauthorized devices connecting
to my broker than a man-in-the-middle attack on a client device.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345534201,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gJcEmID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4
.

[SpiraMirabilis]

Another option would be to use a an authorized mqtt server which each
device would subscribe to. The ESP would send the entire certificate to the
MQTT server, the server would be listening to the topic -- it would
validate the certificate so that you know some strange guy self-signing
www.google.com is not actually google, and send back a yes/no. You'd either
have to wait until the validation occured (I wouldnt like this) or just
serve the request as if it were validated until a Bad Cert message got
posted to the MQTT -- the former is more secure, but the latter is vastly
more usable and probably secure enough

On Sun, Nov 19, 2017 at 10:41 PM, Michael Munson [email protected]

wrote:

The problem is that you have to have the fullchain of the CA certs to
vaidate most certificates, and this is a big issue with the space available
on the serial flash. So a work around is to validate it based on just the
fingerprint, which is not very large at all. But this is not compliant. It
might be good enough, but you'd never know about revocations, etc. What I'd
recommend if for project or org reasons you had to have something that was
more compliant then you could use a HMAC/fingerprint for a VPS/docker based
simple web service -- the ESP would send an API request to the web service
which would validate it and then sign the response with the server's
private HMAC key so you know definitively that the message was sent by your
server (so long as the private key wasnt stolen.) The ESP could potentially
put the fingerprint into a banned list while updating it to a new one, or
similar.

On Sun, Nov 19, 2017 at 10:29 AM, Charlie Waters <[email protected]

wrote:

I'm a little confused by the discussion here. The original question was
whether it is supported to add a certificate and private key to the
firmware for MQTT TLS (presumably for authentication on the server side).
And then the subject changed to CA certificate validation?

It seems the answer to the original question is currently no. But, it
seems that the ESP8266WiFi library supports this, so I don't see why it
couldn't be implemented. A DER private key (2048-bit) and cert should be
<3KiB.

Since a private key is not currently included with the firmware, what is
used for the SSL connection? Is a key generated in memory at startup?

And yes, implementing "real" CA validation may be impossible, but I think
a fingerprint for the server cert is enough for the time being. From a
security standpoint, I'm more worried about unauthorized devices connecting
to my broker than a man-in-the-middle attack on a client device.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345534201,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gJcEmID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4
.

[davidelang]

how do you validate the cert of the MQTT server that you are connecting to in
order to validate certs?

In practice, fingerprints are at least as secure as checking the CA chain, there
are too many different CAs out there that are 'trusted'. Any of them can create
valid certs for any domain.

David Lang

On Mon, 20 Nov 2017, Michael Munson wrote:

Date: Mon, 20 Nov 2017 05:46:42 +0000 (UTC)
From: Michael Munson [e-mail]
Reply-To: arendst/Sonoff-Tasmota
[email protected]>
To: arendst/Sonoff-Tasmota [e-mail]
Cc: David Lang [e-mail], State change [e-mail]
Subject: Re: [arendst/Sonoff-Tasmota] What type of SSL/TLS support is included
in Sonoff-Tasmota? (#146)

Another option would be to use a an authorized mqtt server which each
device would subscribe to. The ESP would send the entire certificate to the
MQTT server, the server would be listening to the topic -- it would
validate the certificate so that you know some strange guy self-signing
www.google.com is not actually google, and send back a yes/no. You'd either
have to wait until the validation occured (I wouldnt like this) or just
serve the request as if it were validated until a Bad Cert message got
posted to the MQTT -- the former is more secure, but the latter is vastly
more usable and probably secure enough

On Sun, Nov 19, 2017 at 10:41 PM, Michael Munson [email protected]

wrote:

The problem is that you have to have the fullchain of the CA certs to
vaidate most certificates, and this is a big issue with the space available
on the serial flash. So a work around is to validate it based on just the
fingerprint, which is not very large at all. But this is not compliant. It
might be good enough, but you'd never know about revocations, etc. What I'd
recommend if for project or org reasons you had to have something that was
more compliant then you could use a HMAC/fingerprint for a VPS/docker based
simple web service -- the ESP would send an API request to the web service
which would validate it and then sign the response with the server's
private HMAC key so you know definitively that the message was sent by your
server (so long as the private key wasnt stolen.) The ESP could potentially
put the fingerprint into a banned list while updating it to a new one, or
similar.

On Sun, Nov 19, 2017 at 10:29 AM, Charlie Waters <[email protected]

wrote:

I'm a little confused by the discussion here. The original question was
whether it is supported to add a certificate and private key to the
firmware for MQTT TLS (presumably for authentication on the server side).
And then the subject changed to CA certificate validation?

It seems the answer to the original question is currently no. But, it
seems that the ESP8266WiFi library supports this, so I don't see why it
couldn't be implemented. A DER private key (2048-bit) and cert should be
<3KiB.

Since a private key is not currently included with the firmware, what is
used for the SSL connection? Is a key generated in memory at startup?

And yes, implementing "real" CA validation may be impossible, but I think
a fingerprint for the server cert is enough for the time being. From a
security standpoint, I'm more worried about unauthorized devices connecting
to my broker than a man-in-the-middle attack on a client device.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345534201,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gJcEmID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4
.

[SpiraMirabilis]

The server would be running a MQTT client connected to itself and
subscribed to the topic. You could do this via bash script or python, in
any case once the ESP submitted a message on the topic the server would be
given both the ESP8266 client and the certificate needed to be verified.
The server has no storage constraints so it can validate the full
certificate, then sends a VALID/INVALID messge to the client who sent the
original message. Since this is a private and encrypted MQTT server you
would know ipso facto that the message is to be trusted, although you could
embed the message in a HMAC hash using a secret key, which the ESP could
then confirm is correct therefore ensuring it is OK to act upon this
message as its sender can be confidently assumed to have the secret key
that nobody but your little MQTT server should have.

I use a similar method to push updates to ESP8266s, the server pushes a
signed UPDATE message and a URL and then the ESPs do the rest.

On Sun, Nov 19, 2017 at 10:57 PM, David Lang [e-mail]
wrote:

how do you validate the cert of the MQTT server that you are connecting to
in
order to validate certs?

In practice, fingerprints are at least as secure as checking the CA chain,
there
are too many different CAs out there that are 'trusted'. Any of them can
create
valid certs for any domain.

David Lang

On Mon, 20 Nov 2017, Michael Munson wrote:

Date: Mon, 20 Nov 2017 05:46:42 +0000 (UTC)
From: Michael Munson [e-mail]
Reply-To: arendst/Sonoff-Tasmota
162a2e4
[email protected]>
To: arendst/Sonoff-Tasmota [e-mail]
Cc: David Lang [e-mail], State change <
[email protected]>
Subject: Re: [arendst/Sonoff-Tasmota] What type of SSL/TLS support is
included
in Sonoff-Tasmota? (#146)

>

Another option would be to use a an authorized mqtt server which each
device would subscribe to. The ESP would send the entire certificate to
the
MQTT server, the server would be listening to the topic -- it would
validate the certificate so that you know some strange guy self-signing
www.google.com is not actually google, and send back a yes/no. You'd
either
have to wait until the validation occured (I wouldnt like this) or just
serve the request as if it were validated until a Bad Cert message got
posted to the MQTT -- the former is more secure, but the latter is vastly
more usable and probably secure enough

On Sun, Nov 19, 2017 at 10:41 PM, Michael Munson <
michael.d.[email protected]

wrote:

The problem is that you have to have the fullchain of the CA certs to
vaidate most certificates, and this is a big issue with the space
available
on the serial flash. So a work around is to validate it based on just
the
fingerprint, which is not very large at all. But this is not compliant.
It
might be good enough, but you'd never know about revocations, etc. What
I'd
recommend if for project or org reasons you had to have something that
was
more compliant then you could use a HMAC/fingerprint for a VPS/docker
based
simple web service -- the ESP would send an API request to the web
service
which would validate it and then sign the response with the server's
private HMAC key so you know definitively that the message was sent by
your
server (so long as the private key wasnt stolen.) The ESP could
potentially
put the fingerprint into a banned list while updating it to a new one,
or
similar.

On Sun, Nov 19, 2017 at 10:29 AM, Charlie Waters <
[email protected]

wrote:

I'm a little confused by the discussion here. The original question was
whether it is supported to add a certificate and private key to the
firmware for MQTT TLS (presumably for authentication on the server
side).
And then the subject changed to CA certificate validation?

It seems the answer to the original question is currently no. But, it
seems that the ESP8266WiFi library supports this, so I don't see why it
couldn't be implemented. A DER private key (2048-bit) and cert should
be
<3KiB.

Since a private key is not currently included with the firmware, what
is
used for the SSL connection? Is a key generated in memory at startup?

And yes, implementing "real" CA validation may be impossible, but I
think
a fingerprint for the server cert is enough for the time being. From a
security standpoint, I'm more worried about unauthorized devices
connecting
to my broker than a man-in-the-middle attack on a client device.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-345534201>,
or mute the thread
ABf2gJcEmID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345598957,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gLlNjpvg_yuCjPlCFPFBELjUYsdUks5s4RTLgaJpZM4MTGq4
.

[SpiraMirabilis]

I mention something, because if you want to just use the fingerprint to
validate one single server, i.e. the producer or consumer of whatever data
your ESP generates then thats fine, probably (until your certificate
changes.) However, it is not uncommon for the applications that I use to
access external REST API.

Certificates change so quickly in this age of free lets encrypt
certificates -- if you want to ensure whatever server you are connecting to
isn't a MITM that will serve you some bad data, or a bad binary if you use
HTTP to do updates then you really need to do a validation on it. For
non-critical things (like checking weather from an API for current
location) that doesnt have a huge impact even if served bad data I do the
request and then validate after via the MQTT method. For critical issues
like downloading a bin that youre going to flash for updates I wait until I
know the server is valid.

If your application is limited to only using a self-signed certificate you
never intend to change, then fingerprint itself is fine. If you are
accessing any external resources, or you dont have control of keeping your
certificate forever (most of us dont) then you need to validate it because
eventually the fingerprint is going to change and then youre fucked, unless
you just assume any new fingerprint is valid if it has the appropriate
domain name.

On Sun, Nov 19, 2017 at 11:02 PM, Michael Munson [email protected]

wrote:

The server would be running a MQTT client connected to itself and
subscribed to the topic. You could do this via bash script or python, in
any case once the ESP submitted a message on the topic the server would be
given both the ESP8266 client and the certificate needed to be verified.
The server has no storage constraints so it can validate the full
certificate, then sends a VALID/INVALID messge to the client who sent the
original message. Since this is a private and encrypted MQTT server you
would know ipso facto that the message is to be trusted, although you could
embed the message in a HMAC hash using a secret key, which the ESP could
then confirm is correct therefore ensuring it is OK to act upon this
message as its sender can be confidently assumed to have the secret key
that nobody but your little MQTT server should have.

I use a similar method to push updates to ESP8266s, the server pushes a
signed UPDATE message and a URL and then the ESPs do the rest.

On Sun, Nov 19, 2017 at 10:57 PM, David Lang [e-mail]
wrote:

how do you validate the cert of the MQTT server that you are connecting
to in
order to validate certs?

In practice, fingerprints are at least as secure as checking the CA
chain, there
are too many different CAs out there that are 'trusted'. Any of them can
create
valid certs for any domain.

David Lang

On Mon, 20 Nov 2017, Michael Munson wrote:

Date: Mon, 20 Nov 2017 05:46:42 +0000 (UTC)
From: Michael Munson [e-mail]
Reply-To: arendst/Sonoff-Tasmota
0000001162a2e4
[email protected]>
To: arendst/Sonoff-Tasmota [e-mail]
Cc: David Lang [e-mail], State change <
[email protected]>
Subject: Re: [arendst/Sonoff-Tasmota] What type of SSL/TLS support is
included
in Sonoff-Tasmota? (#146)

>

Another option would be to use a an authorized mqtt server which each
device would subscribe to. The ESP would send the entire certificate to
the
MQTT server, the server would be listening to the topic -- it would
validate the certificate so that you know some strange guy self-signing
www.google.com is not actually google, and send back a yes/no. You'd
either
have to wait until the validation occured (I wouldnt like this) or just
serve the request as if it were validated until a Bad Cert message got
posted to the MQTT -- the former is more secure, but the latter is
vastly
more usable and probably secure enough

On Sun, Nov 19, 2017 at 10:41 PM, Michael Munson <
michael.d.[email protected]

wrote:

The problem is that you have to have the fullchain of the CA certs to
vaidate most certificates, and this is a big issue with the space
available
on the serial flash. So a work around is to validate it based on just
the
fingerprint, which is not very large at all. But this is not
compliant. It
might be good enough, but you'd never know about revocations, etc.
What I'd
recommend if for project or org reasons you had to have something that
was
more compliant then you could use a HMAC/fingerprint for a VPS/docker
based
simple web service -- the ESP would send an API request to the web
service
which would validate it and then sign the response with the server's
private HMAC key so you know definitively that the message was sent by
your
server (so long as the private key wasnt stolen.) The ESP could
potentially
put the fingerprint into a banned list while updating it to a new one,
or
similar.

On Sun, Nov 19, 2017 at 10:29 AM, Charlie Waters <
[email protected]

wrote:

I'm a little confused by the discussion here. The original question
was
whether it is supported to add a certificate and private key to the
firmware for MQTT TLS (presumably for authentication on the server
side).
And then the subject changed to CA certificate validation?

It seems the answer to the original question is currently no. But, it
seems that the ESP8266WiFi library supports this, so I don't see why
it
couldn't be implemented. A DER private key (2048-bit) and cert should
be
<3KiB.

Since a private key is not currently included with the firmware, what
is
used for the SSL connection? Is a key generated in memory at startup?

And yes, implementing "real" CA validation may be impossible, but I
think
a fingerprint for the server cert is enough for the time being. From a
security standpoint, I'm more worried about unauthorized devices
connecting
to my broker than a man-in-the-middle attack on a client device.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
omment-345534201>,
or mute the thread
ID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345598957,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gLlNjpvg_yuCjPlCFPFBELjUYsdUks5s4RTLgaJpZM4MTGq4
.

[ChaoticEnigma]

Ok, I get all that, but I don't think this thread was about (and I'm not interested in) having the ESP validate the server's cert. Fingerprinting is enough.

I am interested in the ESP sending a certificate (signed by a CA key) to the MQTT server, so the server can authenticate based on the signed certificate alone. Tasmota-Sonoff does not currently support this, so that is what I am looking into.

For example, some other MQTT devices do this with Mosquitto with options require_certificate true and use_identity_as_username true. This avoids the need for client paswords / unique usernames, and you can just generate client keys and signed certs for the ESP.

[SpiraMirabilis]

Ah, I see. If youre just using the certificate as validation of the ESP
client (authentication by certificate) then the MQTT server validates the
certificate, you dont need the full CA chain on the ESP just the
certificate.

This is how you'd do it in C++ and the Arduino VM, its just an example and
I havent tested it but I just tweaked the example for PubSubClient.h. What
is your device trying to do? Tasmota might not have enough memory for its
fancy user interface and TLS. You can try editng the Tasmota source code,
basically all you'd add are the hilighted items in blue below:

include

include

include "certificates.h"

// Update these with values suitable for your network.
const char* ssid = "OurWifiAccessPoint";
const char* password = "OurWPAPassword";
const char* mqtt_server = "broker.meow.com";
const char* client_name = "esp8266_001";const uint8_t* certPK = certificates_esp8266_001_bin_crt; // these variables are defined in certificates.h if you followed the directions
const size_t certSize = certificates_esp8266_001_bin_crt_len; // below
const uint8_t* privKeyPK = certificates_esp8266_001_bin_key;
const size_t privKeySize = certificates_esp8266_001_bin_key_len;
const char* OUR_OUT_TOPIC = "espToServer"; // use this to send commands/data from the esp to the MQTT serverconst char* OUR_IN_TOPIC = "serverToEsp"; // use this to send commands/data from the MQTT to all esp8266sWiFiClientSecure espClient; // change WifiClient to WifiClientSecure to use TLS
PubSubClient client(espClient);

long lastMsg = 0;
String msg;
int value = 0;

void setup_wifi() {

delay(10);
// We start by connecting to a WiFi network Serial.println();
Serial.print("Connecting to ");
Serial.println(ssid);

WiFi.begin(ssid, password);

while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}

randomSeed(micros());

Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
}

void callback(char* topic, byte* payload, unsigned int length) {
Serial.print("Message arrived [");
Serial.print(topic);
Serial.print("] ");
for (int i = 0; i < length; i++) {
Serial.print((char)payload[i]);
}
Serial.println();

// Switch on the LED if an 1 was received as first character if ((char)payload[0] == '1') {
digitalWrite(BUILTIN_LED, LOW); // Turn the LED on (Note that LOW is the voltage level
// but actually the LED is on; this is because
// it is acive low on the ESP-01) } else {
digitalWrite(BUILTIN_LED, HIGH); // Turn the LED off by making the voltage HIGH }

}

void reconnect() {
// Loop until we're reconnected while (!client.connected()) {
Serial.print("Attempting MQTT connection...");
// Create a random client ID

// Attempt to connect    if (client.connect(client_name) {
  Serial.println("connected");
  // Once connected, publish an announcement...      client.publish(OUR_OUT_TOPIC, "hello world");
  // ... and resubscribe      client.subscribe(OUR_IN_TOPIC);
} else {
  Serial.print("failed, rc=");
  Serial.print(client.state());
  Serial.println(" try again in 5 seconds");
  // Wait 5 seconds before retrying      delay(5000);
}

}
}

void setup() {
pinMode(BUILTIN_LED, OUTPUT); // Initialize the BUILTIN_LED pin as an output Serial.begin(115200);
setup_wifi(); espClient.setCertificate(certPK,certSize); // this is the only real extra you add. Just add it bove wherever calls .setServer
espClient.setPrivateKey(privKeyPK,privKeySize);
client.setServer(mqtt_server, 1883);
client.setCallback(callback);
}

void loop() {

if (!client.connected()) {
reconnect();
}
client.loop();

long now = millis();
if (now - lastMsg > 2000) {
lastMsg = now;
++value;
snprintf (msg, 75, "hello world #%ld", value);
Serial.print("Publish message: ");
Serial.println(msg);
client.publish("outTopic", msg);
}
}

However, you can't use the regular certificate files that openssl spits out
for this, you need the binary certificates: Heres the entire process to
create them:

Create CA:

openssl req -new -x509 -days 1095 -extensions v3_ca -keyout ca.key -out ca.crt
>

Create a key and a cert request for the MQTT server:

$ openssl genrsa -out mqtt.key 2048

$ openssl req -out mqtt.csr -key mqtt.key -new

Sign the MQTT certificate with your CA:

$ openssl x509 -req -in mqtt.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out mqtt.crt -days 1095

Now to get the certificates.h in proper format to include with your code (:

$ mkdir certificates

$ openssl x509 -in esp8266_001.crt -out certificates/esp8266_001.bin.crt

-outform DER

$ openssl rsa -in esp8266_001.key -out certificates/esp8266_001.bin.key

-outform DER

$ xxd -i certificates/esp8266_001.*

$ cat certificates/esp8266_001.* > certificates.h

Create a certificate for an individual ESP8266, and sign it with your CA:

$ openssl genrsa -out esp8266_001.key 2048

$ openssl req -out esp8266_001.csr -key esp8266_001.key -new
$ openssl x509 -req -in esp8266_001.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out esp8266_001.crt -days 1095

If youre using like AWS IoT or something for the MQTT you should be good,
if youre using your own MQTT then below:

On MQTT server make a file here: /etc/mosquitto/conf.d/our.conf

Make it something like:

allow_anonymous false

password_file /etc/mosquitto/passwd

listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
keyfile /etc/mosquitto/certs/mosquitto.key
certfile /etc/mosquitto/certs/mosquitto.crt
require_certificate true

Make sure the certs you created are moved to /etc/mosquitt/ca_certificates
and /etc/mosquitto/certs respectively

Make a password/user combination:

$ sudo mosquitto_passwd -c /etc/mosquitto/passwd esp8266_user
>

If you are planning on using a server based python or bash script to
monitor the MQTT for data published, then create another user like above,
maybe named server_user or something (except do not include the -c switch,
as that creates a new file)

Invoke systemctl to restart mosquitto:

$ sudo systemctl restart mosquitto

On Sun, Nov 19, 2017 at 11:11 PM, Charlie Waters [e-mail]
wrote:

Ok, I get all that, but I don't think this thread was about (and I'm not
interested in) having the ESP calidate the server's cert. Fingerprinting is
enough.

I am interested in the ESP sending a certificate (signed by a CA key) to
the MQTT server, so the server can authenticate based on the signed
certificate alone. Tasmota-Sonoff does not currently support this, so that
is what I am looking into.

For example, some other MQTT devices do this with Mosquitto with options require_certificate
true and use_identity_as_username true. This avoids the need for client
paswords / unique usernames, and you can just generate client keys and
signed certs for the ESP.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345600809,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4
.

[SpiraMirabilis]

These steps were in the opposite order, you need to create the esp8266_001
cert/key first.

Create a certificate for an individual ESP8266, and sign it with your CA:

$ openssl genrsa -out esp8266_001.key 2048

$ openssl req -out esp8266_001.csr -key esp8266_001.key -new
$ openssl x509 -req -in esp8266_001.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out esp8266_001.crt -days 1095

Now to get the certificates.h in proper format to include with your code (:

$ mkdir certificates

$ openssl x509 -in esp8266_001.crt -out certificates/esp8266_001.bin.crt

-outform DER

$ openssl rsa -in esp8266_001.key -out certificates/esp8266_001.bin.key

-outform DER

$ xxd -i certificates/esp8266_001.*

$ cat certificates/esp8266_001.* > certificates.h

On Sun, Nov 19, 2017 at 11:11 PM, Charlie Waters [e-mail]
wrote:

Ok, I get all that, but I don't think this thread was about (and I'm not
interested in) having the ESP calidate the server's cert. Fingerprinting is
enough.

I am interested in the ESP sending a certificate (signed by a CA key) to
the MQTT server, so the server can authenticate based on the signed
certificate alone. Tasmota-Sonoff does not currently support this, so that
is what I am looking into.

For example, some other MQTT devices do this with Mosquitto with options require_certificate
true and use_identity_as_username true. This avoids the need for client
paswords / unique usernames, and you can just generate client keys and
signed certs for the ESP.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345600809,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4
.

[KonstantinMastak]

Ok, SSL is about first autentication and then encryption.

SSL fingerprinting is just enough for authentication, on my taste. But what
about encryption? Can we bring some basic encryption to our MQTT channel
which is compatible with general SSL?

2017-11-20 15:30 GMT+04:00 Michael Munson [e-mail]:

These steps were in the opposite order, you need to create the esp8266_001
cert/key first.

Create a certificate for an individual ESP8266, and sign it with your CA:

$ openssl genrsa -out esp8266_001.key 2048

$ openssl req -out esp8266_001.csr -key esp8266_001.key -new
$ openssl x509 -req -in esp8266_001.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out esp8266_001.crt -days 1095

Now to get the certificates.h in proper format to include with your code (:

$ mkdir certificates

$ openssl x509 -in esp8266_001.crt -out certificates/esp8266_001.bin.crt

-outform DER

$ openssl rsa -in esp8266_001.key -out certificates/esp8266_001.bin.key

-outform DER

$ xxd -i certificates/esp8266_001.*

$ cat certificates/esp8266_001.* > certificates.h

On Sun, Nov 19, 2017 at 11:11 PM, Charlie Waters >
wrote:

Ok, I get all that, but I don't think this thread was about (and I'm not
interested in) having the ESP calidate the server's cert. Fingerprinting
is
enough.

I am interested in the ESP sending a certificate (signed by a CA key) to
the MQTT server, so the server can authenticate based on the signed
certificate alone. Tasmota-Sonoff does not currently support this, so
that
is what I am looking into.

For example, some other MQTT devices do this with Mosquitto with options
require_certificate
true and use_identity_as_username true. This avoids the need for client
paswords / unique usernames, and you can just generate client keys and
signed certs for the ESP.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-345600809>,
or mute the thread
ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345669302,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYvBk9E8bbF-fwOI6qq6BjOvF9qkRGuGks5s4WK7gaJpZM4MTGq4
.

[SpiraMirabilis]

If you use WiFiClientSecure instead of WiFiClient you can use TLS 1.1. Just
see my example above. You definitely need the full 160mhz on the ESP
though. Try it out with Tasmota, it may be too much for it in which case
you'll have to pair Tasmota down for memory/ticks. Sonoffs with ESP32s will
be awesome, since theyre so beefy and have a built-in hardware encryption
coprocessor for RSA. ESP32 still a bit pricey for what the sonoff usually
used for.

On Mon, Nov 20, 2017 at 4:43 AM, KonstantinMastak [e-mail]
wrote:

Ok, SSL is about first autentication and then encryption.

SSL fingerprinting is just enough for authentication, on my taste. But what
about encryption? Can we bring some basic encryption to our MQTT channel
which is compatible with general SSL?

2017-11-20 15:30 GMT+04:00 Michael Munson [e-mail]:

These steps were in the opposite order, you need to create the
esp8266_001
cert/key first.

Create a certificate for an individual ESP8266, and sign it with your CA:

$ openssl genrsa -out esp8266_001.key 2048

$ openssl req -out esp8266_001.csr -key esp8266_001.key -new
$ openssl x509 -req -in esp8266_001.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out esp8266_001.crt -days 1095

Now to get the certificates.h in proper format to include with your code
(:

$ mkdir certificates

$ openssl x509 -in esp8266_001.crt -out certificates/esp8266_001.bin.crt

-outform DER

$ openssl rsa -in esp8266_001.key -out certificates/esp8266_001.bin.key

-outform DER

$ xxd -i certificates/esp8266_001.*

$ cat certificates/esp8266_001.* > certificates.h

On Sun, Nov 19, 2017 at 11:11 PM, Charlie Waters <
[email protected]
>
wrote:

Ok, I get all that, but I don't think this thread was about (and I'm
not
interested in) having the ESP calidate the server's cert.
Fingerprinting
is
enough.

I am interested in the ESP sending a certificate (signed by a CA key)
to
the MQTT server, so the server can authenticate based on the signed
certificate alone. Tasmota-Sonoff does not currently support this, so
that
is what I am looking into.

For example, some other MQTT devices do this with Mosquitto with
options
require_certificate
true and use_identity_as_username true. This avoids the need for client
paswords / unique usernames, and you can just generate client keys and
signed certs for the ESP.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-345600809>,
or mute the thread
ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
issuecomment-345669302>,
or mute the thread
fwOI6qq6BjOvF9qkRGuGks5s4WK7gaJpZM4MTGq4>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345672058,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gE4ZB1FTdOUNr-NyaeJ-_cIglaDxks5s4WXWgaJpZM4MTGq4
.

[KonstantinMastak]

Michael,

Am I right that WiFiClientSecure not only provides SSL fingerprinting check
but also provides SSL encryption? If yes, what type of encryption it is?

2017-11-20 15:47 GMT+04:00 Michael Munson [e-mail]:

If you use WiFiClientSecure instead of WiFiClient you can use TLS 1.1. Just
see my example above. You definitely need the full 160mhz on the ESP
though. Try it out with Tasmota, it may be too much for it in which case
you'll have to pair Tasmota down for memory/ticks. Sonoffs with ESP32s will
be awesome, since theyre so beefy and have a built-in hardware encryption
coprocessor for RSA. ESP32 still a bit pricey for what the sonoff usually
used for.

On Mon, Nov 20, 2017 at 4:43 AM, KonstantinMastak <
[email protected]>
wrote:

Ok, SSL is about first autentication and then encryption.

SSL fingerprinting is just enough for authentication, on my taste. But
what
about encryption? Can we bring some basic encryption to our MQTT channel
which is compatible with general SSL?

2017-11-20 15:30 GMT+04:00 Michael Munson [e-mail]:

These steps were in the opposite order, you need to create the
esp8266_001
cert/key first.

Create a certificate for an individual ESP8266, and sign it with your
CA:

$ openssl genrsa -out esp8266_001.key 2048

$ openssl req -out esp8266_001.csr -key esp8266_001.key -new
$ openssl x509 -req -in esp8266_001.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out esp8266_001.crt -days 1095

Now to get the certificates.h in proper format to include with your
code
(:

$ mkdir certificates

$ openssl x509 -in esp8266_001.crt -out certificates/esp8266_001.bin.
crt

-outform DER

$ openssl rsa -in esp8266_001.key -out certificates/esp8266_001.bin.
key

-outform DER

$ xxd -i certificates/esp8266_001.*

$ cat certificates/esp8266_001.* > certificates.h

On Sun, Nov 19, 2017 at 11:11 PM, Charlie Waters <
[email protected]
>
wrote:

Ok, I get all that, but I don't think this thread was about (and I'm
not
interested in) having the ESP calidate the server's cert.
Fingerprinting
is
enough.

I am interested in the ESP sending a certificate (signed by a CA key)
to
the MQTT server, so the server can authenticate based on the signed
certificate alone. Tasmota-Sonoff does not currently support this, so
that
is what I am looking into.

For example, some other MQTT devices do this with Mosquitto with
options
require_certificate
true and use_identity_as_username true. This avoids the need for
client
paswords / unique usernames, and you can just generate client keys
and
signed certs for the ESP.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-345600809>,
or mute the thread
ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
issuecomment-345669302>,
or mute the thread
fwOI6qq6BjOvF9qkRGuGks5s4WK7gaJpZM4MTGq4>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-345672058>,
or mute the thread
auth/ABf2gE4ZB1FTdOUNr-NyaeJ-_cIglaDxks5s4WXWgaJpZM4MTGq4>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345672842,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYvBk1F7ZYZZkGzh3XrD6ByCTrClPnZNks5s4Wa8gaJpZM4MTGq4
.

[SpiraMirabilis]

I believe it is TLS 1.1

On Mon, Nov 20, 2017 at 5:08 AM, KonstantinMastak [e-mail]
wrote:

Michael,

Am I right that WiFiClientSecure not only provides SSL fingerprinting check
but also provides SSL encryption? If yes, what type of encryption it is?

2017-11-20 15:47 GMT+04:00 Michael Munson [e-mail]:

If you use WiFiClientSecure instead of WiFiClient you can use TLS 1.1.
Just
see my example above. You definitely need the full 160mhz on the ESP
though. Try it out with Tasmota, it may be too much for it in which case
you'll have to pair Tasmota down for memory/ticks. Sonoffs with ESP32s
will
be awesome, since theyre so beefy and have a built-in hardware encryption
coprocessor for RSA. ESP32 still a bit pricey for what the sonoff usually
used for.

On Mon, Nov 20, 2017 at 4:43 AM, KonstantinMastak <
[email protected]>
wrote:

Ok, SSL is about first autentication and then encryption.

SSL fingerprinting is just enough for authentication, on my taste. But
what
about encryption? Can we bring some basic encryption to our MQTT
channel
which is compatible with general SSL?

2017-11-20 15:30 GMT+04:00 Michael Munson [e-mail]:

These steps were in the opposite order, you need to create the
esp8266_001
cert/key first.

Create a certificate for an individual ESP8266, and sign it with your
CA:

$ openssl genrsa -out esp8266_001.key 2048

$ openssl req -out esp8266_001.csr -key esp8266_001.key -new
$ openssl x509 -req -in esp8266_001.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out esp8266_001.crt -days 1095

Now to get the certificates.h in proper format to include with your
code
(:

$ mkdir certificates

$ openssl x509 -in esp8266_001.crt -out certificates/esp8266_001.bin.
crt

-outform DER

$ openssl rsa -in esp8266_001.key -out certificates/esp8266_001.bin.
key

-outform DER

$ xxd -i certificates/esp8266_001.*

$ cat certificates/esp8266_001.* > certificates.h

On Sun, Nov 19, 2017 at 11:11 PM, Charlie Waters <
[email protected]
>
wrote:

Ok, I get all that, but I don't think this thread was about (and
I'm
not
interested in) having the ESP calidate the server's cert.
Fingerprinting
is
enough.

I am interested in the ESP sending a certificate (signed by a CA
key)
to
the MQTT server, so the server can authenticate based on the signed
certificate alone. Tasmota-Sonoff does not currently support this,
so
that
is what I am looking into.

For example, some other MQTT devices do this with Mosquitto with
options
require_certificate
true and use_identity_as_username true. This avoids the need for
client
paswords / unique usernames, and you can just generate client keys
and
signed certs for the ESP.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-345600809>,
or mute the thread
ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
issuecomment-345669302>,
or mute the thread
fwOI6qq6BjOvF9qkRGuGks5s4WK7gaJpZM4MTGq4>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-345672058>,
or mute the thread
auth/ABf2gE4ZB1FTdOUNr-NyaeJ-_cIglaDxks5s4WXWgaJpZM4MTGq4>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
issuecomment-345672842>,
or mute the thread
AYvBk1F7ZYZZkGzh3XrD6ByCTrClPnZNks5s4Wa8gaJpZM4MTGq4>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Sonoff-Tasmota/issues/146#issuecomment-345677597,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABf2gKMzjy0zYx4TRj0eh3tMLklWf-EUks5s4WvWgaJpZM4MTGq4
.

[ChaoticEnigma]

@SpiraMirabilis That's quite the comprehensive guide there. I've actually already done pretty much exactly what you describe. I added setCertificate and setPrivateKey calls right before the connect/verify on WifiClientSecure in MqttReconnect in sonoff.ino. Unfortunately, it doesn't seem the client is serving the key to the server (or the server doesn't like it).

I also noticed the ESP8266Wifi library provided by platformIO is much older than the upstream version at esp8266/Arduino, which purportedly supports TLSv1.2 now. Maybe worth the time to pull a copy of that into Sonoff-Tasmota? I may give that a shot if I don't have luck with the current version.

I'm currently working on some Wifi signal issues, I will get back to this and determine if the WifiClientSecure is actually sending the certificate.

[thunberg]

I'm new to this topic, but coming at it from the position of wanting to be able to use a Sonoff-Tasmota to connect to AWS IoT, which requires certificate authentication.

It appears what's needed is esp8266/Arduino 2.4, which has axTLS 2.x which has TLS 1.2:

https://github.com/esp8266/Arduino/releases

Further it seems there are already examples of this implemented:

https://github.com/copercini/esp8266-aws_iot

[thunberg]

Has there been any progress on this? Would love a clean way to use Sonoff devices on AWS.

[hackbar]

I'd also like to use Sonoff to with Google IoT Core, which has the same TLS and cert requirements as AWS.

[vaijab]

I'd also like to use Sonoff to with Google IoT Core, which has the same TLS and cert requirements as AWS.

I am looking for a solution to this. How are people connecting their sonoff devices to Google IoT Core at the moment?

[vogelfreiheit]

Are there any instructions built for compiling in the SSL support?