In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?
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.
IMO this should always be pushed back against, because it's not a valid excuse. If the hardware is too constrained to support appropriate security then that hardware is not appropriate for the application (or no longer appropriate for the application, as the story often goes).
> can be trivially MITMed
Crazy how poor security can be even from a purported security vendor.
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)
Well, it does support DDNS, [1] so presumably some people do assign it a domain name. But I don't expect it to participate in WebPKI necessarily. That's not the only way to secure communication from the config program to the device, e.g.:
* The routers I worked on in 2006 had baked-in keys/certs signed by our own CA with cn based on serial number rather than reachable customer-chosen FQDN. That's not WebPKI but it actually works. Elk's configuration software knows the expected serial number and could use a similar approach. The configuration is not http-based (much less browser-based) anyway.
* It'd be better to just punt and say the communication should be secured by proxy or VPN or something than to offer TLS in a misleading way and suggest it should be directly exposed to the Internet.
As for the Ethernet expander to the central station, that totally could use TLS and WebPKI.
[1] https://elk-manuals.s3.amazonaws.com/M1XEP_v2_Installation_M... page 14
https://news.ycombinator.com/item?id=50166579 - “eMudhra intermediate CA compromise” - 947 points | 19 hours ago | 408 comments
https://news.ycombinator.com/item?id=50177916 - "Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds" - 604 points | 7 hours ago | 270 comments
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!
This fact alone though makes that very unlikely.
[0] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...
These days thats up to 15 years. Talk about programmed obsolescence.
If you don't, you can never tell what a device is sending/receiving, and devices have a hardcoded end-of-life date where they become useless. Would love to see groups starting to push in this direction.
umm, they had already been maintaining the program for almost a decade at that point.
So many words for such a simple point/claim...