YHK - yet another hacker news clone

This is unfortunately accurate, sometimes due to real constraints and more often due to loose threat models. I am hopeful that more open source firmware options (e.g. Zephyr RTOS) and more software investment from silicon vendors is helping to change the status quo. That being said, we are still a long way away from a "Let's Encrypt movement" for embedded devices.

> physical security system

> can be trivially MITMed

Crazy how poor security can be even from a purported security vendor.

Over a decade ago, I created an AWS ELB to serve a production API. It was HTTPS-only, using an Amazon-signed certificate served from ACM for my employer's domain. Right after deployment, logs showed a regular pattern of 404s trying to POST/PUT to my API at paths I didn't support. Thousands of requests per hour, and they continued for days. It didn't look like a DoS--the paths looked like someone else's API.

I got curious what all the traffic was, so I added a route to the API that saved some of the uploaded data. It was live home surveillance video and photos! Indoors, outdoors, baby monitors, living rooms, etc. It was pretty easy to find which vendor's hardware was doing this (from headers, paths, watermarks) and I reached out to their security contact to let them know what I found. They responded generically but didn't seem to care that much.

In short, because HTTPS was required, and an ELB gets assigned IPv4 addresses arbitrarily, I can only conclude that a whole fleet of home security cameras were sold across the US that hard-coded the IP address of their cloud server and had certificate validation disabled.

Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI? The vendor similarly has no interest in explaining its buyers how to do that so it can connect "securely" to their particular alarm monitoring service.

There are some goodish options for how we could secure communications with local network devices hosting simple configuration WebUIs, but the browser vendors have overwhelmingly demonstrated that they have no interest in any of them. So what you ship is HTTP, not even the self-signed certificate, that just gets scary messages.

(What the browser vendors seem to want, to be clear, is that your gadget reaches out securely to the Vendor Cloud^TM, and you similarly use your Google and Apple notarized smartphone to reach out to that same Cloud, so you can talk to the hardware sitting a meter away from you)

Of all the places for what is otherwise eMudhra's epic fail, various MCUs was the one place I thought perhaps there'd be some silver lining. Some interesting and good, for the hackers: to get to have some chance to see what their devices are doing, to man-in-the-middle those conversations home those devices in our homes are doing, and see what they are saying.

This fact alone though makes that very unlikely.

I don't think that applies here. The trust store contains the _root_ certificate, not these intermediates.

The main eMudhra root cert backing these intermediates is "emSign ECC Root CA - G3", which was issued back in 2018 and was widely trusted for TLS way before these intermediates were created. The certs were also cross-signed by Sectigo using their "AAA Certificate Services" which was issued in 2004 (!!!) and was trusted in TLS stores until 2025 (after that it got removed/demoted to email signing only, depending on the store).

Everything which trust one of those roots will trust the intermediates (putting aside revocation, CT checks, lack of ECC support, etc) so the window is much much longer. The AAA does expire at the end of 2028 though!

IoT devices typically run on MCUs and they have WiFi connections, often. The price of MCUs with WiFi has gone down dramatically. Often $5 or less for a MCU capable of WiFi and usually Bluetooth. Think, ESP32-S3 and such.