Thoughts on Project Connected Home over IP (CHIP)

In late December 2019 Google, Amazon, Apple and a number of other companies announced Project Connected Home over IP. Like all Internet of Things I thought I would dig into it and see what it’s made up of.

First thoughts before I even began to dig were basically “well they got there eventually!” as I’ve long believed that for IoT in the home to be successful as a whole there needs to be a single set of open standards that all devices speak so that the things can intercommunicate…. you know, just like the internet! But like so many of these things the big companies always attempt to see if they can control the entire market first, then realise they need to “compromise” and work with the other players on standards, which is when the market starts to actually mature and consumers start to win out!

If you look at the project’s web site there’s, at least at the time of writing, 16 company logos on the page, of which around six or seven I would consider household names. A standard such as this was always going to happen. If you look at the “Home IoT Market” it’s a mish-mash of competing and incompatible standards, none of which really have a lead and some of the big names, such as Apple with their HomeKit interface (I refuse to use the term “standard”), have been struggling to get any real level of foot hold in the market. Some of the more popular off the shelf devices have been things like Samsung’s “SmartThings” which implement a number of different radios etc as bridge/gateway devices to make other things work together, which in and of itself speaks volumes. If the companies themselves didn’t get themselves sorted out it would have ended up in governments mandating something. In short the whole category is a big mess!

So reading through the FAQ and various bits in the media about it what does it appear to do? It puts IP over stuff! Shocking right!? To quote the FAQ:

The goal of the first specification release will be Wi-Fi, up to and including 802.11ax (aka Wi-Fi 6), that is 802.11a/b/g/n/ac/ax; Thread over 802.15.4-2006 at 2.4 GHz; and IP implementations for Bluetooth Low Energy, versions 4.1, 4.2, and 5.0 for the network and physical wireless protocols.

So the technologies they’re using are WiFi, no real shock there, although there’s no mention of Wi-Fi HaLow AKA 802.11ah but for home use that’s nothing of note. Next up in Bluetooth LE, 4.1 – 5.0, again no real surprises here, there’s already a standard for IP over Bluetooth LE/mesh in the form of 6LoWPAN, the same as used by Thread and vanilla 802.15.4, slightly interesting they mentioned explicitly 3 versions of BT-LE and just didn’t say BT-LE in general as all versions support IP. The final option mentioned was 802.15.4, the bit that I find particularly interesting here is that Zigbee Alliance was one of the four companies in the original announcement, 802.15.4 is an open radio standard used by Zigbee, Thread, 6LoWPAN directly and a number of other protocols, Zigbee has their own Zigbee IP standard, which competes with Thread and others yet Thread, originally out of Google/Nest is the chosen one. I’ve also found Thread to not really be a completely open standard like TCP/IP, as while there is the OpenThread implementation, you need to be a paying member of the Thread Group organisation to have it certified!

So what else does the project offer? They mention the following but note the term “may include”.:

This may include a proposed standard for lifecycle events such as provisioning/onboarding, removal, error recovery, and software update.

I feel that the lifecycle events they mention are actually extremely important here, and standards in this area are just as important as connectivity standards such as IP for layer 3. If you look at components such as provisioning/onboarding there’s fairly new standards evolving such as the Intel/Arm FIDO secure device onboarding collaboration which are still quite new so I suspect they’re going to wait and watch these before making a decision which is actively a good thing in my opinion if it means one less new standard!

Overall there’s currently nothing actually new on offer here in terms of standards, what is new is a number of large companies committing to focusing on a single Layer 3 connectivity protocol. There’s already widely available hardware across WiFi/Bluetooth/802.15.4 as well as standard IP implementations for them all. This should actively replace Zigbee, Z-Wave and a number of other proprietary Layer 2/3 protocols and should be straight forward for adoption as there’s not actually a lot for anyone else to do.

I feel this is a move in the right direction and will make life easier for a lot of third parties who want their products to work with “the big three of Apple/Google/Amazon”, the move to more open standards is obviously good, but overall there’s really nothing particularly new other than another mechanism for closed companies to work together. I don’t think it’ll ultimately make much difference in general to the open source community as those companies will have their proprietary protocols/APIs sitting on top of IP, just like in other parts of the internet now. It’ll be interesting to see how open the process is once they release code and start to work on it.

Basically it’s a wait and watch so really I’m ¯\_(ツ)_/¯

Securing home networks and IoT for family at holiday time

Many people head home to family at some point over the holiday season, whether that be like today for Thanksgiving in the US, Christian Christmas at the end of December or one of the many and varied holidays. During that time most people that are technical will be asked to help fix or setup various computer or internet related devices that family members that are not so technical have acquired or broken since the last time they ventured home. For me it use to be the regular upgrade/replacement of the Virus Scan and anti malware software. These days it tends to be patching of phones and tablets and all sorts of other devices.

So what can the average technical person do to help minimise risks to family members, or stop them from being part of a large botnet sometime in the future, without making the technology hard or even impossible for family to use, or to minimise the calls throughout the year.

Router

The first port of call should always be the router. Often these just get stuffed in the corner, on a bookshelf or somewhere out of site and forgotten. From a security point of view they are the most important, they are the thing that primarily protects everything else as they’re the ingress/egress point of the network. So what to do and change on these devices:

  • Upgrade the firmware to the latest supported version, and configure it to auto-upgrade if it’s an option. If the last firmware is ancient consider moving to a third party firmware like LEDE Project or an OpenWRT dirivative. Worst case scenario throw it away and give them a new one as their present.
  • Change the admin password.
  • Change the SSID and set a reasonable password.
  • Ensure that the admin interface isn’t available on the WAN link, do a port scan.
  • Turn off port forwarding and UPnP on the router.
  • Switch it to OpenDNS (208.67.222.222 208.67.220.220), Google Public DNS (8.8.8.8 4.4.4.4), the new Quad9, or even better a combination of them so if one service goes down or disappears their internet will still work.

Phones and Tablets

Ensure the phone is set to auto install new OS firmware releases, also ensure that apps are set to auto update and that if the provider, such as Google Play, has a malware scan option in their App store ensure that’s turned on so it’ll clean up any apps that are discovered to be problematic.

TVs, Bluerays and other Media Players

It’s surprising the number of these devices that have network connections and never get updated. In some cases the network functionality is rarely, if ever used, I know I’ve pretty much disconnected all Blu-ray players from networks, turned off the wireless if it has it, and not ever had a complaint. Often it’s better to replace some of old network media devices with ones that are actively maintained such as Google Chromecast, Amazon Fire, Roku etc. It’s also worth checking if any of these devices have the ability to connect to via ad-hoc means and disable that to limit connections to only those that are on the standard home network.

Various IoT devices

IoT devices should generally, if at all possible, be isolated on their own network. This is easy if as part of securing the router you moved it to LEDE or something similar above, and configure it to have a strict deny-by-default policy. Check the existing network for devices that are connected to it. In some cases there may have been a device connected to it some time ago that have long been forgotten about and are no longer in use, or the manufacturer has ceased to exist and they’re just a compromise waiting to happen masquerading as an expensive paperweight. Those that are in use might not be using the IoT/network functionality, if so turn the network off. Those that remain obviously ensure they’re running the latest firmware, set for auto update, and if possible move them to the IoT network. In some cases it might be possible or better to replace connected lighting if it’s some terrible WiFi/Bluetooth globe with something like the IKEA TRÅDFRI system as it has reasonable security, is of good quality and is affordable. Also don’t forget to check for things like doorbells, locks, cameras and other such devices.

Conslusion

Securing the router and associated DNS is by far and large the most important thing to do, it will help mitigate/protect most of the other problems that loom on the inside. But disconnecting, throwing away, replacement of old devices is sometimes the easiest way to fix them too, or else isolating them.

Let me know what else people do, and what I missed.

Configuring HTTP/2 with Apache on Fedora

HTTP/2 is the new version of the well known HTTP protocol which has been at the venerable 1.1 since late last century. Version 2 was derived out of Google’s SPDY protocol and it’s a binary protocol over the text based 1.1. It introduces a bunch of improvements including reducing latency, multiplexing, and server push. There’s some useful improvements that will be great for things like apps that use WebSockets. The Apache httpd daemon has included complete support for HTTP/2 since the 2.4.17 release in the form of mod_http2.

First you should configure your site with SSL, I suggest using LetsEncrypt/certbot as documented in this Fedora Magazine article.

Then you need to make sure the module is loaded, at least in Fedora 25 this is enabled in /etc/httpd/conf.modules.d/00-base.conf by default:

LoadModule http2_module modules/mod_http2.so

Then you just need to enable the protocol in either the general configuration or in specific VirtualHost directives for specific sites:

# for a https server
Protocols h2 http/1.1

# for a http server
Protocols h2c http/1.1

Then it’s just a systemctl restart httpd to make the changes take effect.

To test whether you’re serving over HTTP/2 you can test using this HTTP/2 testing site or with the OpenSSL client (check for “ALPN protocol: h2” in the output) with the following command:

openssl s_client -alpn h2 -connect HOSTNAME:443

Note: HTTP/2 is not currently supported in the httpd shipped in RHEL.

Connect to a wireless network using command line nmcli

I use a lot of minimal installs on various ARM devices. They’re good because they’re quick to download and you can test most of the functionality of the device to ensure it’s working or to quickly test specific functionality but of course it doesn’t have a GUI to use the nice graphical tools which are useful to quickly connect to a wifi network or other things.

This where nmcli comes in handy to quickly do anything you can do with the GUI. To connect to a wireless network I do:

Check you can see the wireless NIC and that the radio is enabled (basically “Airplane” mode):

# nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN    
enabled  enabled  enabled  enabled 
# nmcli device
DEVICE  TYPE      STATE         CONNECTION 
wlan0   wifi      disconnected  --         
eth0    ethernet  unavailable   --         
lo      loopback  unmanaged     --         

Then to actually connect to a wireless AP:

# nmcli device wifi rescan
# nmcli device wifi list
# nmcli device wifi connect SSID-Name password wireless-password

And that should be enough to get you connected. You can list the connection with nmcli connection and various other options. It’s pretty straight forward. The only complaint I have is that it doesn’t prompt for a password if you leave it out so it means the AP password is stored on the command line history. Not a major given it’s quite easy to find where it’s stored anyway on the system but it would be a useful addition.

Cheap travel routers

In the past I’ve traveled for work, conferences and personal a lot. The first category has declined a little from the “travel all the time” I’ve done in the past since I’ve joined the release engineering team. When travelling regularly I have a collection of things I pack that make life easier and a little more pleasant.

On of these is a travel router, often hotels have wired but no wireless, or flaky wireless or you need to pay for more than one device (or even one device). I don’t have a high spec need but it must have the following:

  • Dual ethernet WAN/LAN (everyone knows I have lots of ARM devices!)
  • Wireless, doesn’t need to be massivly fast (hotel internet is the bottle neck!) but it does need to be stable
  • Standard power cables, either figure 8 plug with inbuilt switching PSU or micro USB
  • Small
  • Open source and hackable. Probably supportable with OpenWRT
  • Quick and easy to reconfigure

For a number of years the device I used was an Apple Airport Express as it was one of the few that met most of the above criteria. But then I stopped using a iPod touch which meant the last option was dead due to the lack of openness.

Time for a new one! I’ve been looking for a while, I almost went for the popular TP-Link WR703N router as it’s well supported in OpenWRT but it meant that I lost the extra wired network port.

Then I came across the NEXX WT3020. It comes in four official options all of which have 802.11n, dual 100Mb ethernet, and runs from a micro USB connector! All but the bottom end model have a USB port for 3G or storage. The top two models just seem to have SW options but no other HW. Perfect, it even has OpenWRT support! So I went with the WT3020H, all for around $20.

I ordered one, while I was awaiting for it to arrive the OpenWRT project released Chaos Calmer 15.05-rc1 which has a prebuilt image and literally in less than five minutes I’d reflashed it to OpenWRT via the standard web flash interface! I’ve not had time to test performance, throughput and features such as USB but it seems to work pretty well for a $20 router and all the core features I need are working and it’s in a form factor that is TINY and I don’t even need to take an extra power supply. I’d call that a WIN!