[frazar0]

> If the device was validating the server certificate, it wouldn’t make it this far, so that shows that our certificate was accepted.

One more very good reason for preventing requests to "the cloud".

However, I find it funny that the lack of proper certificate validation (which is a security issue in principle) is a pre-requisite for the "de-cloudification" process.

[alias_neo]

It is funny, but it's also the defacto-standard.

I avoid as much as possible, devices with cloud connections, but those which I somehow end up with anyway that do have such services, I've found almost none of them do any sort of certificate validation.

Load up any certificate you like on your MiTM proxy and go to town.

Sadly, despite embedded hardware being much more capable, some of them having hardware secure-elements and cryptographic extensions, people making these devices either don't have the expertise or just don't care.

Once upon a time I dreamt of creating IoT devices with security, openness and longevity in mind.

[8organicbits]

I built a small device as a hobby a couple years back using an ESP32. It has 500KB of memory, so storing a full set of CA certs was quite limiting. I forget the size, but looking at Ubuntu package repo, perhaps 100KB. So the constraint was storage size (and therefore hardware cost). I ended up making it local network only and using unencrypted HTTP, which worked for my use case.

[alias_neo]

> so storing a full set of CA certs was quite limiting

Not sure what your project was doing, but one doesn't generally want to install a full set of CAs. If you're creating a product that'll talk to your APIs you pin your own CA, ensure that the server name matches and verify it, anything else is a failure.

[8organicbits]

If you use an API endpoint provided by a cloud service provider then you use whichever CA they use, which will be a public CA. But they can switch to another at any time.

[pmontra]

I think that they know that the maintenance of the certificate on their server could be a big point of failure, maybe out of their control, so they disable any validation on the client.

A self renewing free certificate (eg: Letsencrypt) still requires some maintenance. A non free certificate also costs money. It's probably a no-no for many of those manufacturers or the company that give them the servers. Razor thin margins, know how, dedicated staff, etc.

[alias_neo]

> I think that they know that the maintenance of the certificate on their server could be a big point of failure

If you're building products that talk only to your APIs, you issue your own CA, at the very, very minimum you can put a fingerprint in the end-device to verify it, that can be updated OTA if you need to change the CA/server-cert because you kept the lifetime short.

My experience is that for people outside of the "security" space (I'm in secure-comms, backend), most of them don't have a clue. Some believe the only solution is a cert issued by some "trusted" org like LE, others don't know what pinning or verification is, self-sign is often mis-used as a term for self-CA, and then more generally speaking understanding or TLS is low.

The low-resource nature of microcontrollers has certainly made it difficult to do this well/easily in the past, but with micro-sized TLS libraries, and secure-elements on board many of them now, it can absolutely be done with a little effort and understanding. Coupled with EC/certs keys with smaller memory footprints and hardware-crypto accel the only take home I can find in any of this, is that these people simply don't give a shit about the security of the devices they sell and the data about their end-users they're spitting out.

> Razor thin margins, know how, dedicated staff

Half of this "smart" junk is sold at overinflated prices thanks to the "smart-tax". I have a heater which has an ESP32 and you manage it with an app (which I won't do), they spent a bunch on the app, put an ESP32 and some other electronics in what otherwise could have been a £20 heater instead of a £80 heater, and yet I can MiTM their TLS MQTT connection because they make no effort to protect it, all while this thing is spewing mountains of environmental data up to their cloud every 30 seconds that could quite easily be used to detect presence, amongst other things in my home, even when the thing isn't running.

I'm biased being a dev in the security space, but this sort of careless approach shouldn't be allowed when selling consumer electronics. Fortunately, in the UK, NCSC is making efforts to improve this with security labels[0] and requirements at PoS for consumer electronic devices, and I hope to see it develop further.

[0] https://www.ncsc.gov.uk/files/Security-law-smart-devices-NCS...

[jkestner]

We're trying to hit those three checkboxes with the environmental monitor/data logger we're shipping in a few months. Certificate to talk to our server, but you can also just point it at any MQTT broker.