
More awful IoT stuff - edward
http://mjg59.dreamwidth.org/43486.html
======
CaptSpify
I just blogged about this yesterday. In short:

> The line in the sand for me is: network vs cloud-based systems. I _want_
> things to be network connected, but I want it for my own network only. I
> want to be able to control my coffee pot, but only from home. If I _choose_
> to expose this over the internet, great! It's up to me to make sure it's
> secure. I don't want anyone making that decision for me.

I also want it to be upgradeable, and hackable. I'm willing to pay a lot of
money for standalone quality devices, but nobody is supplying!

~~~
nbadg
Would you feel comfortable with end-to-end encryption via an open, documented,
free protocol? This is literally my raison d'être as a company, so I'd be
interested to hear your comfort level.

What I've got is a platform that 1.) makes it substantially easier for IoT
developers to get their devices to market and 2.} enforces end-to-end
encryption and affirmative consensual sharing. It works by running as a
background service on both the IoT device and on any connecting computers. In
a similar vein to IPFS, the service magically switches between local and
nonlocal networks dynamically, so it doesn't matter if your interent
connection goes out; as long as you have power (and a local server set up, but
I'd like to add P2P capability over LAN in the near future) you're good to go.

I realize this isn't the whole device you want, but is that a starting point
you'd be interested in?

~~~
DougN7
I've been debating about hooking my garage door opener up using a built-in
feature so I could open the door from my iPhone. I don't trust that whatever
central site I'll be connected to is safe. If I _knew_ the vendor had
implemented your protocol/software well, and I _knew_ your software was safe,
yeah, I'd use it. But I don't know those two things, so no way am I hooking my
home's door up to the Internet...

~~~
nbadg
In my case you actually do know that the vendor is using the protocol. You
would have to be running the protocol on (in this example) your iPhone in
order to talk to it. Everything is client-side verified and enforced by
encryption.

You wouldn't have any guarantee that the garage door opener isn't also running
a separate web connection in the background, but arguably unless you're
actively monitoring your LAN (or just plain radio) traffic you don't have that
anyways.

Put a different way, you can't prevent your manufacturer from, for example,
adding a SIM card and wireless connection to your garage door opener. At some
point you have to trust them.

~~~
DougN7
When you say I'd have to be running the protocol, wouldn't I really be running
their garage door opener app? In other words, how do I know your protocol is
being used?

~~~
nbadg
If they were using the protocol, they have two options:

1\. Roll their own implementation (highly discouraged). Increase their
development burden. Introduce higher maintenance burden. Slightly more
flexibility for app deployment. And run the risk of my company disallowing
interoperable embedded commercial implementations out of security concerns for
the users. Basically, at this point the company is better off not using the
protocol.

2\. Use our implementation (Hypergolix). Massively decrease development and
maintenance burden. They now have an install dependency, though, so
distribution is a bit more complicated. Significant reduction in time and
money invested in the app.

The critical point is this: with option 1, you're correct in that you don't
know the protocol is in use, but it's extremely likely that they wouldn't be
using it here, nor advertise that they were. With option two, you know that
they are using it, because _you have to manually install the application to
run the protocol._

~~~
DougN7
With #2 do I know they are using your additional install? Would your app
indicate their app was a registered client and was sending commands through
it?

~~~
nbadg
It certainly could, as it has full knowledge of what's connected. That's quite
a ways down the road though; for now we're focusing on Razpi <-> computer.
Mobile deployment is much more complicated (also a much larger market though).

------
diggan
So there is a great amount of lists, blogposts and information about awful/bad
IoT things, but if someone like me want to have a list about IoT things that
are actually secure and well-working, where would I find that?

~~~
manyxcxi
It's not that easy. I stick with brands/products that are reviewed by people I
trust or have seemed to pick up some momentum.

My general rule of thumb is I NEVER buy anything IoT that is WiFi based.
Zigbee or Z-Wave based devices will save you a lot of security nightmares
(though definitely not all).

~~~
pavel_lishin
Why is Z* preferable to Wifi-based?

~~~
gnur
One of the reasons would be that it isn't used that often and won't allow
access to your network with commodity hardware.

~~~
EarthIsHome
Isn't this idea hiding the problem though? While using uncommon hardware and
protocols may thwart certain users, it's really not solving the problem of
security. It's somewhat similar to the idea of using a hidden wireless network
and calling that security instead of securing your network with WPA2, etc.

As these devices become more popular, we'll start seeing more Zigbees and
Z-wave devices become commodity hardware.

~~~
Dayshine
Not at all, anyone can "join" the network, but nobody can decrypt the traffic
without the key.

Zigbee has built-in, easy, encryption. You simply set your router to allow
unsecured joins temporarily whenever you get a new device, which then learns
the key.

When the network is set to allow only secure joins only devices pre-configured
with the key can see anything other than encrypted frames.

------
Klathmon
>It's running Linux and includes Busybox and dnsmasq, so plenty of GPLed code.
I emailed the manufacturer asking for a copy and got told that they wouldn't
give it to me, which is unsurprising but still disappointing.

Has the GPL really lost it's power that much? I mean not responding to
inquiries is one thing, but outright saying no?

~~~
oliwarner
Lost its power? This is just copyright apathy. Nothing new, especially in
China. Look at it from the manufacturer's point of view. They know how
expensive this would be to take to China and prosecute and they know they're a
tiny fish. It's simply a reasoned gamble that saying no is the fastest, most
efficient way to get this dealt with. Much easier than auditing the code,
having the developer separate out sensitive data, etc. Well before you
consider the long term archiving of this stuff. They're probably already
making the next generation of this rubbish.

I dare say if this were a major manufacturer, more effort would be made to
make them behave, but we're talking about a short-run switch here.

If there ever becomes a mechanism to DMCA-takedown physical products on an
international level, we might see some movement here. But China (et al) would
never, ever agree to that. It's hard enough to get them to block things that
clearly break international safety standards.

~~~
josho
This makes me wonder how imports are handled. If I can buy a third party power
supply from a US based order system (amazon), and this ps is dangerous (eg.
those knock off Apple power supplies). How is this legal, presumably the
device hasn't passed safety regulations here. So, there must be some way to
stop this product from entering the country. Why isn't that mechanism
happening?

Same applies for this device. If a mfg is infringing on copyright then
shouldn't we have a mechanism to stop it from being imported?

It strikes me that we have two laws in this country. The laws for those with
money/power (e.g. MPAA to protect US corporate media interests), and then
those same laws that are not applied to protect consumers. Is the only
difference that MPAA has lawyers to ensure copyright infringement stops while
consumers don't?

~~~
ehntoo
I cannot speak to copyright, but there seem to be mechanisms in place for
stopping import of trademark infringing goods to the US. See for example the
run-in which SparkFun had with importing lookalike Fluke Multimeters a few
years ago:
[https://www.sparkfun.com/news/1428](https://www.sparkfun.com/news/1428) and
previous HN discussion here:
[https://news.ycombinator.com/item?id=7428799](https://news.ycombinator.com/item?id=7428799)

This might actually do more to confirm than dispute your comment about "laws
for those with money/power", though.

------
apozem
> Eventually I plugged my phone into my laptop and ran adb logcat, and the
> Android debug logs told me that the app was trying to modify a network that
> it hadn't created. Apparently this isn't permitted as of Android 6, but the
> app was handling this denial by just trying again. I deleted the network
> from the system settings, restarted the app, and this time the app created
> the network record and could modify it. It still didn't work, but that's
> because it let me give it a 5GHz network and it only has a 2.4GHz radio, so
> one reset later and I finally had it online.

Madness. And people wonder why there's so much skepticism about IoT being
adopted by non-techies.

~~~
deelowe
As a counter example, my brother who never uses a computer setup his
chromecast in 5 minutes with zero help from me. I know b/c he called me and
asked for help. I told him he wouldn't need it, but he didn't believe me.

Things are getting better. There will always be more crap out there than good
stuff. That's why walmart is so popular, but things will generally improve.

~~~
omni
I don't consider Chromecast as being part of IoT. Chromecast is mostly used as
an internet media device, whereas I usually interpret IoT as slapping Internet
capabilities on traditional appliances (light bulbs, fridges, whatever).
Curious what other people think.

~~~
seizethecheese
Chromecast _is_ slapping Internet capabilities on a traditional appliance
(TV).

~~~
omni
Only in as much as it lets you access content streams on the Internet. It
doesn't let you control your TV via the cloud or anything. In terms of
functionality I think it's pretty comparable to any other content stream you
can hook up to your TV, going back to Ataris and VCRs.

------
bedhead
@internetofshit is a great follow and pretty quickly illustrates just how
absurd the IoT rush has become. Solutions in search of problems.

~~~
mcphage
> Solutions in search of problems.

Solutions in search of money before the market wises up to how crap these
products are.

~~~
imtringued
a bit off topic. Why can't somebody sell a reasonably priced Thunderbolt 3
eGPU enclosure. Oh right intel's certification process takes several months...
All in the name of quality assurance yet most thunderbolt 3 products feel
subpar considering their price.

------
FussyZeus
There's so much potential in the market for proper, well made IoT devices that
would bring around the hardcore skeptics like myself. I mean really well made
products, properly encrypted with well made API endpoints that come with good
apps for the uninitiated -AND- the ability to be scripted and automated by the
techies. (You can do both, there's no reason why you can't and I don't
understand why everyone refuses to). Oh, and not having them phone home to
who-knows-where-istan around Australia, or at the very least, having the
ability to TURN THAT OFF.

Seriously why have NO companies come forward with products like this. I'd buy
a house worth if someone did.

~~~
tunap
The commercial side of building automation is robust, but the components are
pricey, the platforms proprietary* and end-user aavailibility seems to be
limited. The beauty of the _other side_ is every switch, sensor & controller's
first objective is _not_ to monetize the user but rather to simply do it's
intended job. Look into building automation controls and you will find what
you yearn for; Siemens, Johnson Controls, Honeywell/Novar, BAS... However,
retail/public access, setup & end-user friendliness will still be significant
hurdles outside of hiring a pricey, authorized contractor.

*The components are simple & generic, the interface & controls are mostly based on a universal framework w/ their proprietary gui/front-end locked on.

~~~
FussyZeus
That's what I'm getting at though, there is clearly a market for consumer
ready devices that don't cost what solutions like that do and don't need a
contractor to install them. I mean you can't tell me that in today's world we
couldn't manufacture an outlet with electronic control of the flow of current
out of it's outlets, and do it in such a way that uses proper SSL and
endpoints, without having to price it so high? I don't believe it.

~~~
tunap
I totally agree, the demand & the means exist. However, the intent of retail
providers is _anything but_ enabling simple, automated controls. Everything is
about grabbing the data cash bag and, as an afterthought, let's _personalize_
your experience. I have been pondering this and the only conclusion I can come
up with is the market controllers(more than mere "forces") have much to gain
by selling the perception instead of reality and their treasure troves of
patents(from commercial side) allow them to maintain this position. IMO, the
digital revolution of ours has transformed sharing into one way collecting and
the consumers into commodities. Both of which I find quite offensive, and
sometimes, outright hostile. Alas, our money is our only true vote. Vote
accordingly.

~~~
FussyZeus
I suppose but it still seems like a copout (not on you of course, on them) to
play the brand lock-in game. You don't need a centralized server to
personalize and operating those servers, even on something like AWS, costs
money. Why not put that on the consumer instead? Many consumers I know would
prefer the roll-your-own solution and it saves the manufacturer money.

~~~
tunap
Thanks for your manners, but it is probably a copout on my part. I have the
wherewithal(-money) to build something like this in my own home but I believe
most of these controls are over-engineered progress for progress' sake... for
anything less than a few thousand square foot structures. All I really need is
a programmable thermostat, a couple timer plugs & my 'routine'. As always,
YMMV.

As for the providers, I have to admit, a service economy cannot sustain itself
using only transactional relations. In order to ensure future revenues, a
contracted service agreement &/or proprietary walled garden approach is the
only sustainable model they have come up with. I am a 'break-fix' geezer stuck
in my ways and don't subject my clients to lock-in, but my widely varying
income from month to month can make affording life difficult at times.

edit: + _& /or proprietary walled garden approach_

~~~
FussyZeus
But this is assuming that I expect something beyond the transaction. I don't.
I expressly DON'T want a continuing relationship where Nest decides my
perfectly functional thermostat no longer works or that Phillips decides their
controller is only going to work with Phillips light bulbs.

I want them to sell me the product and then politely f*ck off so it keeps
working. :)

------
mschuster91
I'd like regulation agencies to mandate, as a condition of market entry, for
each and every electronic product:

1) Full firmware source code and required toolchains/sign keys/... be
submitted to the national libraries, to be kept for secure archival until the
device is officially unsupported by the manufacturer.

2) For networked products, the full source code must be either published, or
licensed institutes must perform a security check.

3) There must be provisions in place to ensure timely reactions in case of
security issues. If the manufacturer does not respond to security issues,
national libraries have the right to release the source code.

4) Required tools, service manuals, datasheets etc. must be submitted to the
national libraries.

This should basically kill off GPL-abusing companies, as well as ensure
serviceability, even for discarded products.

~~~
Finnucane
Interestingly, Underwriters Laboratory is starting to get into this game:

[http://www.ul.com/cybersecurity/](http://www.ul.com/cybersecurity/)

How good or useful this will be I don't know. But clearly they see this as an
area where people will be looking for some expert help; not everyone has the
skill of a Linux kernel hacker to check these things for themselves.

------
alexmingoia
The principal reason devices need to be connected is so that business can hold
your devices ransom and charge you money to use them.

Turn on lights with a phone? No need for Internet.

Open doors with a fingerprint? No need for Internet.

An auto-adjusting energy-saving thermostat? No need for Internet.

A fridge that knows the milk is low? No need for Internet.

Charge people money to use their toaster? You need the Internet for that.

~~~
saulr
Completely agree except the light argument -- having my lights cloud connected
allows me to control them remotely. The main use for this is for time or
sunrise/sunset scheduling. However you could quite easily architecture this
without cloud connectivity, it seems easiest to keep the bulb dumb and keep
the 'smarts' elsewhere (whether that's on a phone locally or a server in the
cloud).

~~~
TeMPOraL
Scheduling isn't stock market, you don't need a live feed for that. All such a
bulb needs is an accurate date and time source - the rest, including (if you
also add one-time geographical area input) the sunrise/sunset times can be
determined with a little bit of trivial math on the uC that said "smart" bulb
already has.

All that IoT stuff doesn't need Internet access. Hell, most of it doesn't need
much of a network at all, but just having them default to _intranet_ would
deliver all the value without the problems (and the rent-seeking).

------
Feneric
IoT devices can be fine, but there are lots of companies involved in it that
don't know what they're doing and would be better off staying out of the
market. I always advice friends / family to look for upgrading capabilities,
ability to do useful work when not connected to the Internet proper, user
control (do you _own_ this device or effectively borrow it per licensing
etc.?), and other similar things before purchasing any IoT device. Some IoT
devices are great, but some are abysmal.

~~~
Klathmon
And it sounds like this one was like 80% of the way there. I mean they used
encryption (badly, but they still used it), had a way to update the software
on the device (even if only over http), and uses passwords (although doesn't
enforce them).

~~~
pjc50
So everything it does, it does badly? To me, that's not 80% of the way there,
that's more like -80%.

~~~
Klathmon
Come on, the last thing he reviewed sent everything in plaintext, had no root
password, called out to multiple chinese servers, ran ssh via a hardcoded
password that was something like a simple word, and didn't have any way of
actually updating the code on the device. Oh, and it barely even functioned as
a lightbulb...

This is lightyears better than that, and yeah they fucked up a bunch of stuff,
but it at least shows they tried. Even shitty AES is going to increase
security over plaintext...

~~~
snoman
Agreed. It may not be technically good, but it's as good as the door locks
that hundreds of millions of people rely on to protect their homes every day.
Most home doors/deadbolts are easily pickable with a few weeks' practice.

It keeps honest people honest.

~~~
Klathmon
I somewhat agree. Since it's only a plug, if the worst that a hacker can do is
turn your plug on and off, it's not the end of the world.

But if there is a vulnerability that lets someone use this plug to pivot an
attack on the rest of your machines in your network, now it's a big fuckin
deal.

------
jsondata
I also mentioned this in a recent blog post:
[https://www.jsondata.io/blog/2016/iot-needs-a-
cloud/](https://www.jsondata.io/blog/2016/iot-needs-a-cloud/)

> Right now, the cloud - especially for IoT - isn't a healthy ecosystem. Your
> shiny new smart thermostat might as well be dialing into AOL on a dedicated
> landline. And unlike public services, these proprietary service providers
> lack long-term guarantees of service availability.

> What we need is a push for openness and interoperability in the cloud, and
> that will only happen if consumers demand it. The service providers are
> incentivized to do just the opposite.

~~~
daveguy
>What we need is a push for openness and interoperability in the cloud

Personally I think that is the opposite of what we need. Most IoT devices
should be local-network-only. So if by cloud you mean a personal cloud (local
network or VPN), then yes, I agree. Otherwise keep the interwebs away from my
thermostat.

~~~
jsondata
That's a fair point, and I agree. However, the reality is that a major selling
point for these things is along the lines of "control it from anywhere", and
whether people actually need remote access or not, it seems that a lot of
consumers still see it as a major upside.

Maybe what we really need are more consumer-friendly, self-hosted (and secure)
home VPN options. That way you _can_ just run your services on the local
network, and still have remote access without opening your devices to the
world (or to other companies' servers). Until the average grandma can do that,
the "personal cloud" idea will probably be overshadowed by manufacturers'
desire to provide proprietary remote access options, because those go hand-in-
hand with things like subscription pricing models, data mining, etc.

~~~
tdkl
Or change the marketing from cloud connected to owning the cloud. I mean, for
someone who would depend on stable Internet connection to be able to control
all this shit, he'd be off hosting a personal cloud on the same connection as
well. Even better, because if there are operations happening in a local
network and WAN goes out, the devices will still operate inside the LAN.

------
stcredzero
_The short version: they introduced terrible vulnerabilities on your network,
they violated the GPL and they were also just bad at being..._

 _Overall: the hardware seems fine, the software is shoddy and the security is
terrible_

This article begins and ends with two great tl;dr for IoT. There is value in
this. Just look at the prevailing cluelessness, and be much better than that
to stand out from the pack. In fact, how about applying that formula to the
next nascent big thing that comes along?

~~~
adyus
Perhaps because the large mass of consumers only care about the first point
(how the hardware looks in their home)?

Point two comes in play only if the user experience is horrible, otherwise
it's acceptable.

Regular consumers rarely think about point three.

~~~
stcredzero
I wasn't suggesting consumers think about these issues. I was suggesting that
founders think about them!

~~~
TeMPOraL
There's that Upton Sinclair quote about understanding and salary...

The point being, the business model of IoT is literally lending you a device
that due to purposefully shitty engineering is not useful if you're not paying
the rent. I wish there'd be a founder that cares about making stuff that's
primarily _delivering_ value to the customer, but in IoT space, I'm yet to
hear about one.

------
SEJeff
Shameless plug to a 100% OSS IoT / home automation system I contribute to that
agrees. Everything IoT should be fully open source and not rely on cloud
connections:

[https://home-assistant.io/blog/2016/04/05/your-hub-should-
be...](https://home-assistant.io/blog/2016/04/05/your-hub-should-be-local-and-
open/)

------
almostarockstar
Sounds like there is a strong need for a standard OS build for IoT devices.

I'm not expert in the area, but I would imagine a standard API could be
implemented to handle the vast majority of use cases. Connecting to an app
securely, turning things on and off, basic scheduling.

~~~
anilgulecha
I think openwrt on the main unit (a good router) + nodemcu based sensor units
would work well.

Openwrt is powerful enough to take care of logging, connecting to the internet
etc, and the sensor units can form a pseudo mesh using their wifi
capabilities.

~~~
throwaway7767
Ideally the base should be from a project that handles base system upgrades,
so that consumers don't have to trust that the vendor is building security
updates in a timely manner.

Last I checked, OpenWRT did not do security updates, and it's up to the user
to recompile everything if they want newer versions.

------
m12k
I feel that the people who are now talking about IoT are the same people who
were totally into 'semantic web' back in the day. And it's pretty much the
same kind of story: "Wouldn't it be neat if all these systems could
interoperate?" and again the answer is "Yes, but not neat enough justify the
cost and hassle of actually making it happen".

~~~
jbpetersen
I think we're due for a proper realization of the semantic web in the next
couple years. Things seem about at the point where the cost and hassle can be
overcome without a significant financial motivation to do so.

Maybe in another decade or so IoT will make sense other than as something fun
to experiment with.

------
steven2012
The stuff from wirelesstags.net are generally very good. I have a bunch of
sensors and their Reed sensors for detecting opening and closing of doors are
very good. I hook it up with ifttt and turn on my Hue lights when I open and
close my doors. Clearly not ground breaking stuff but useful.

The Hue lights are great but expensive. The Hue switch made things a lot more
useful as well. I'm waiting for them to come out with a compatible light
switch so I can control my recessed lights the same way as my light bulbs.

What they need to work on is a better outdoor camera with motion detection
that doesn't get triggered by shadows or wind moving a tree branch. I've tried
almost every solution and none is acceptable.

~~~
georgehotelling
The wirelesstags.net stuff looks good, but it also is tied to their cloud
services. I couldn't find a local API to talk to their bridge device.

The nice thing about Hue is that their bridge can run completely disconnected
from the internet and still respond to RESTful API requests, which means that
when Phillips end-of-lifes Hue my bridge will keep working with Home
Assistant.

~~~
steven2012
Yes that was a concern of mine as well. They stated that if they do go out of
business they would open source everything so that we could build our own
solution. That's basically what convinced me to go all in with their product.

------
coldpie
Does anyone still need convincing? Don't buy anything that connects to the
Internet that isn't built and maintained by a major software company. Even
then, be careful. Duh.

~~~
brianwawok
Not sure if software company helps. Nest has some issues.

------
jussaskin
IoT is all about unsecured devices generally?

~~~
marktangotango
That's been my understanding as well. The cpu's used typically aren't powerful
enough to do anything other than simple encryption in a reasonable amount of
time. Ssl is generally out of the question. Someone please educate me if
that's incorrect.

~~~
jerf
As usual, "it depends".

If this thing is capable of running OpenWRT, it can run some sort of SSL for
what it needs. Might be tight and might have to not be OpenSSL, but it can be
done.

Lesser-capable devices may have issues. But note that one way or another, the
devices _must_ speak some decent encryption to get on to WPA2 networks. Of
course that's probably done in the Wifi hardware, but it still shows that it's
not like we're living in the 1980s where we literally wouldn't have been able
to afford the silicon in a consumer device. Hardware acceleration of SSL
shouldn't be that hard to get a hold of, for instance:
[https://en.wikipedia.org/wiki/SSL_acceleration#Central_proce...](https://en.wikipedia.org/wiki/SSL_acceleration#Central_processor_support)

~~~
peterwwillis
But more to the point: there is no purpose to SSL/TLS on an appliance because
it will not have a valid certificate, hence it won't protect anything. You
might as well just use WPA2-PSK.

~~~
jerf
If you're using a custom client-side app to access the device, which many of
these things seem to do, you can create a CA for the devices, put the public
cert for the CA into the app, and issue each device an individual cert at the
factory signed by that CA. Then the app can be reasonably secure and assured.

I say only "reasonably" because defending against the "I cracked into the
device and stole its cert" is pretty hard, but I'd submit, also not all that
realistic a threat in this case. I'm really looking to defend more against "I
bashed together some encryption so crappy I can hack this by making you visit
a hostile web page" than "I want to use this lightbulb without the NSA
knowing". (On that note, an SSL cert only valid to a custom app that your
browser won't accept isn't _all_ bad, it prevents that sort of thing.)

I mean, this it total pie-in-the-sky in terms of the ask I'm making here for
security knowledge and willingness to do something correctly instead of
bashing out some terrible, incorrect crypto with direct and incorrect use of
the primitives. But it's _possible_.

Actually... I won't call myself an SSL expert per se, but one of the things
that I find personally frustrating in dealing with some people is that once
you do know what's going on, using SSL is often _much much_ simpler than
bashing together your own crap crypto. Any sensible SSL library has places to
stick the CA certs. Generating them isn't _that_ hard, more just tedious.
Generating a big pile of certs at the factory and siging them isn't _that_
hard. Even if you're very sloppy with your SSL usage, where you don't do a
great job of protecting your core cert, where you use the root of the CA
instead of an intermediate so the private key of the root is "live" in the
factory, you don't set up a good revocation solution and you just set the
expiration as far into the future as you can, because you probably haven't got
a mechanism for updating them... even if you make all those errors, it's
_still_ better than just bashing crap crypto together, because it'll still
resist more attacks than your crap crypto and it's not really all that hard.

But I have abundant experience that shows people would way rather futz around
directly with RSA keys and HMAC and spend days and weeks scraping something
together rather than even entertain the suggestion of doing it even _half_
correctly. I don't fully understand it. Do other people find futzing with
crypto that fun? I play defense a lot in security, but I honestly find correct
crypto a royal pain in the ass and do everything I can to outsource it via SSL
(which may not be perfect but isn't necessarily _bad_ and has the advantage of
being very defensible when people ask "what do you do to secure things") or
NaCL or something. Is it just the psychological difficulty of admitting that
you don't _really_ know what you're doing with this crypto stuff? I dunno.

~~~
peterwwillis
Nobody's going to invest money into flashing each device with an individual
cert just to protect against an attacker MITMing a home user's home wifi
network to turn off a lamp. And you'd have to bundle your own whole TLS stack
and browser with the app just to get the CA validated; that's a lot of extra
software engineering.

If the user _really_ cares about security enough, they can buy their own real
TLS cert and install the cert on the brick.

~~~
jerf
Ah, I meant to add to my list of bad practices sticking the same cert on every
device. Sorry. To be clear, I'm saying you got me on that one. I missed that.

Of course, one person steals that cert and they've cracked the system wide
open. But that's the default case for crap crypto anyhow, so what's the
difference, except you spent about 10 minutes in the shell and passed some
parameters to your library instead of spending.... well... _anything_ more
than 10 minutes futzing around with AES and RSA and so on?

Also, while I understand your use of "nobody" in the slangy English sense
rather than the strict mathematical sense, I would point out that as these
devices get more sophisticated, eventually they tend towards a manufacturing
process that _will_ do something to each one in the factory anyhow. For
instance, if you're doing any sort of burn-in testing you've already done the
vast bulk of the hard work it would take to also use that time to stick a cert
on there. Yeah, your cheap knock-off Wifi light won't do that, but as the
industry matures I think you'll see practices that would permit certs without
much additional work.

------
Serow225
Alright so this is mostly OT, but I figured people who are into IoT might be
able to help; does anyone know of a setup that would easily let me control a
remote AC outlet by plugging a sensor into an existing hard-switched AC
outlet? I'd rather not deal with installing a hub and programming scenes etc.
Thanks!

------
nkg
I enjoy reading this kind of article about lousy security, because I say to
myself "Wow, that was lousy!" and laugh. BUT I still don't know how I could
avoid this. I genuinely ask: could anyone share with me the "2016 Guide of the
best pratices for securing an API/ a web app"?

~~~
jimktrains2
TLS + Client Certs + EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH

~~~
pandemicsyn
You forgot to mention +[Vault|CFSSL|XYZ] for cert management.

~~~
jimktrains2
I can find what CFSSL[1] and Vault[2] are, but not XYZ in this context.

Also, all of this can be done with plain openssl, there is no need for
additional tools.

[1] [https://blog.cloudflare.com/introducing-
cfssl/](https://blog.cloudflare.com/introducing-cfssl/) [2]
[https://www.vaultproject.io/intro/](https://www.vaultproject.io/intro/)

------
ufmace
Hold on - it sounds like this thing is running Android. Has reference to
connecting with ADB, apks, and Android versions. But it's also running a SSH
server and OpenWRT? What's going on there, is it running 2 different OSes for
some reason, or did they somehow merge Android and OpenWRT?

~~~
janjongboom
The app is running Android, the device is OpenWRT as far as I understand.

------
Chris2048
I'm enthusiastically waiting for this:
[https://espressif.com/en/products/hardware/esp32/overview](https://espressif.com/en/products/hardware/esp32/overview)

oh baby!

------
manyxcxi
Funny timing... I just bought an LG LFXS30776S refrigerator and the first
thing I noticed was that all of a sudden I had a new WiFi broadcast. Turns out
that according to tech support there's no way to shut this off.

~~~
ethbro
Transceiver, meet grounded aluminum foil?

~~~
smarks
Has it come to the point where your refrigerator has to wear a tinfoil hat?

~~~
ethbro
Yes.

------
Wi11Jeffries
There is definitely a lot of IoT stuff coming out that isn't great. However
MFT companies like Aspera, Innorix, and Attachmate must be loving it~

------
dimino
Sorry, but what does he mean by "infringing on my copyright"?

Is he the author of one of the libraries it uses?

~~~
josteink
Yes. He is a major contributor to the Linux kernel, and unless I remember
incorrectly, he was almost single handedly responsible for getting UEFI
support in Linux.

------
DrNuke
Just offload your entire IoT project to a big firm / provider instead of
cherrypicking devices?

------
peterwwillis
Has anyone ever bought a consumer network appliance that didn't have shitty
security?

~~~
source99
Has a security engineer ever reviewed anything that had good security?

~~~
peterwwillis
Yes, but mainly commercial stuff. It costs 3-10x what the consumer appliances
cost but it's usually actually secure and stable. Aruba, Ruckus, Cisco, Meru,
etc.

