What type of SSL/TLS support is included in Sonoff-Tasmota? #146
Labels
question
Type - Asking for Information
Comments
|
Correct. If you know of an esp8266 SSL/TLS implementation using only 470MB with your wishes just let me know. |
|
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:
However, it is not clear for me if these steps will result in client->server authentification. Maybe, not. |
|
if you have a server on permises you can use stunnel and have the server/computer handle SSL and proxy traffic to the ESP8266 |
|
@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 |
|
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... |
|
Thank you for all your answers! This really makes sense. I'll go on with fingerprinting. |
|
Just wanted to share this here: https://github.com/copercini/esp8266-aws_iot Also a related discussion: |
|
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" ***@***.***> 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
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABf2gEfSiwwAMHMjWYZCfQy41ICUry1cks5rnboCgaJpZM4MTGq4>
.
|
|
@KonstantinMastak, Have you ever solved or to formulate fingerprint instead uploading AWS Certificates (cert.pem, private.key, CA.pem) to Tasmota? |
|
@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 <[email protected]>:
… @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
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYvBky_5qFCHlSCayL8_FbbBiymOPZGNks5sq-DogaJpZM4MTGq4>
.
|
|
@KonstantinMastak, Is it possible to use Tasmota with AWS IoT? |
|
I don't know. I never used AWS IoT.
2017-10-12 14:13 GMT+03:00 Sunrise17 <[email protected]>:
… @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
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYvBk7rjlAFCSM9JVgK-UdzrkLOvMx7uks5srfQ7gaJpZM4MTGq4>
.
|
|
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. |
|
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 ***@***.***> 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
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABf2gJcEmID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4>
.
|
|
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 ***@***.***
> 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
> <#146 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABf2gJcEmID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4>
> .
>
|
|
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 ***@***.***>
Reply-To: arendst/Sonoff-Tasmota
<reply+0021b24fd19baae49cc451bdf69173d418c97e4deeea74b892cf00000001162a2e4
***@***.***>
To: arendst/Sonoff-Tasmota ***@***.***>
Cc: David Lang ***@***.***>, State change ***@***.***>
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 ***@***.***
> 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 ***@***.***
>> 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
>> <#146 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/ABf2gJcEmID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4>
>> .
>>
>
>
|
|
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 <[email protected]>
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 ***@***.***>
> Reply-To: arendst/Sonoff-Tasmota
> <reply+0021b24fd19baae49cc451bdf69173d418c97e4deeea74b892cf00000001
162a2e4
> ***@***.***>
> To: arendst/Sonoff-Tasmota ***@***.***>
> Cc: David Lang ***@***.***>, State change <
***@***.***>
> 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 <
***@***.***
>> 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 <
***@***.***
>>> 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
>>> <#146
issuecomment-345534201>,
>>> or mute the thread
>>> <https://github.com/notifications/unsubscribe-auth/
ABf2gJcEmID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4>
>>> .
>>>
>>
>>
>
>
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABf2gLlNjpvg_yuCjPlCFPFBELjUYsdUks5s4RTLgaJpZM4MTGq4>
.
|
|
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 ***@***.***>
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 ***@***.***>
> > Reply-To: arendst/Sonoff-Tasmota
> > <reply+0021b24fd19baae49cc451bdf69173d418c97e4deeea74b892cf0
> 0000001162a2e4
> > ***@***.***>
> > To: arendst/Sonoff-Tasmota ***@***.***>
> > Cc: David Lang ***@***.***>, State change <
> ***@***.***>
> > 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 <
> ***@***.***
> >> 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 <
> ***@***.***
> >>> 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
> >>> <#146 (comment)
> omment-345534201>,
> >>> or mute the thread
> >>> <https://github.com/notifications/unsubscribe-auth/ABf2gJcEm
> ID61x161ivHzeaC1LCZjBm2ks5s4GVcgaJpZM4MTGq4>
>
> >>> .
> >>>
> >>
> >>
> >
> >
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#146 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABf2gLlNjpvg_yuCjPlCFPFBELjUYsdUks5s4RTLgaJpZM4MTGq4>
> .
>
|
|
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 |
|
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 <ESP8266WiFi.h>
#include <PubSubClient.h>
#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 ***@***.***> 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
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
.
|
|
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
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
.
|
|
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 <[email protected]>:
… 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
> <#146
issuecomment-345600809>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYvBk9E8bbF-fwOI6qq6BjOvF9qkRGuGks5s4WK7gaJpZM4MTGq4>
.
|
|
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 ***@***.***>:
> 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
> > <#146
> issuecomment-345600809>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-auth/
> ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#146
issuecomment-345669302>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AYvBk9E8bbF-
fwOI6qq6BjOvF9qkRGuGks5s4WK7gaJpZM4MTGq4>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABf2gE4ZB1FTdOUNr-NyaeJ-_cIglaDxks5s4WXWgaJpZM4MTGq4>
.
|
|
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 <[email protected]>:
… 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 <
***@***.***>
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 ***@***.***>:
>
> > 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
> > > <#146
> > issuecomment-345600809>,
> > > or mute the thread
> > > <https://github.com/notifications/unsubscribe-auth/
> > ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
> > > .
> > >
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#146
> issuecomment-345669302>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-auth/AYvBk9E8bbF-
> fwOI6qq6BjOvF9qkRGuGks5s4WK7gaJpZM4MTGq4>
>
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#146
issuecomment-345672058>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-
auth/ABf2gE4ZB1FTdOUNr-NyaeJ-_cIglaDxks5s4WXWgaJpZM4MTGq4>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AYvBk1F7ZYZZkGzh3XrD6ByCTrClPnZNks5s4Wa8gaJpZM4MTGq4>
.
|
|
I believe it is TLS 1.1
On Mon, Nov 20, 2017 at 5:08 AM, KonstantinMastak <[email protected]>
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 ***@***.***>:
> 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 <
> ***@***.***>
> 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 ***@***.***>:
> >
> > > 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
> > > > <#146
> > > issuecomment-345600809>,
> > > > or mute the thread
> > > > <https://github.com/notifications/unsubscribe-auth/
> > > ABf2gG1VIderL7XDFy6zqd0vg5mS7Ag9ks5s4RgegaJpZM4MTGq4>
> > > > .
> > > >
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > > Reply to this email directly, view it on GitHub
> > > <#146
> > issuecomment-345669302>,
> > > or mute the thread
> > > <https://github.com/notifications/unsubscribe-auth/AYvBk9E8bbF-
> > fwOI6qq6BjOvF9qkRGuGks5s4WK7gaJpZM4MTGq4>
> >
> > > .
> > >
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <#146
> issuecomment-345672058>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/ABf2gE4ZB1FTdOUNr-NyaeJ-_cIglaDxks5s4WXWgaJpZM4MTGq4>
>
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#146
issuecomment-345672842>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AYvBk1F7ZYZZkGzh3XrD6ByCTrClPnZNks5s4Wa8gaJpZM4MTGq4>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABf2gKMzjy0zYx4TRj0eh3tMLklWf-EUks5s4WvWgaJpZM4MTGq4>
.
|
|
@SpiraMirabilis That's quite the comprehensive guide there. I've actually already done pretty much exactly what you describe. I added 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. |
|
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: |
|
Has there been any progress on this? Would love a clean way to use Sonoff devices on AWS. |
|
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? |
|
Are there any instructions built for compiling in the SSL support? |
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
The text was updated successfully, but these errors were encountered: