Confirmation that my recommendations to run SSL/TLS even on your LAN between devices is a good idea. While the article does discuss how to disable HTTPS in the browser for some sites, it won’t be able to do so quite so easily for connections that ONLY work using TLS like MQTT.
WPA 2 has been out long enough I really didn’t expect such a serious flaw to be discovered this late.
Heed the article’s advice, update your devices when updates become available.
Thanks for posting the warning.
Just being a “good citizen” 
For those of you using Ubiquiti’s UniFi APs, Ubiquiti has released a firmware update that fixes the KRACK vulnerability.
DD-WRT is fixed as well, http://svn.dd-wrt.com/changeset/33525
For the uninitiated… Can someone confirm that patching a router will resolve the issue or do I need to do something to all the esp8266 devices on my network?
If you patch your router and your ESP8266s never leave your wireless network you are OK leaving them unpatched. Devices like laptops, phones, and tablets should be updated because these devices are likely to connect to other networks which may still be vulnerable to this flaw.
Please note that patching the Router is not enough. The attacker can modify traffic between your Wi-Fi device and your Router (and OpenHAB). So he can stand in front of you door, hijack the traffic of your Tablet to control turn off the security system or open up the door. Everthing controllable over the webinterface or REST API is controllable if unpatched devices.
Using HTTPS will help, because the secure connection is established before the URL is sent to OpenHAB. So no readable /basicui/CMD?alarm_system=OFF. As the attacker can not initiate new traffic but only modify it enroute, he cannot guess the encryption keys and cannot send commands to OpenHABs HTTPS services. If using HTTPS (and really, HTTPS is the only way to communicate with openhab) you do not have to patch your device to use it.
You can also use a VPN for your LAN devices. Yes, a VPN from and to you own local network. This will encapsulate all the traffic in the encrypted VPN data. If you use a VPN you do not need to patch your device. A VPN Server has to run on your router or a device that is connected to your Router/Switch via a cable and not Wi-Fi.
If you want to limit the devices with access to OpenHAB to known devices only, you can install a reverse proxy and use client certificates. You generate a client certificate for every device that should be allowed to access OpenHAB and install it on the device. The reverse proxy will check if it knows the client and only forward legit requests to the real OpenHAB server.
I have some room panels running an old Android version and I will never receive patches for it. So I will switch to HTTPS and Client Certificates now.
OK, now that I’ve read the actual paper rather than just random press articles about KRACK I retract my previous posting. The attack is against the clients so patching the router will not necessarily be sufficient since the attacker has to set themselves up as a man-in-the-middle between the client and the router.
It is important to emphasize that this attack does require the attacker to be relatively physically close to your network to pull it off. This significantly reduces the likelihood parameter in the risk calculation (Risk = Likelihood of successful attack * Impact of successful attack). Before anyone spends a whole lot of time and effort beyond patching their devices, make sure it is worth your time.
Personally, I believe that all you really need to protect yourself from the casual bad actor is to run faster than your neighbors rather than the bear.[1] This cuts two ways. Is your house easier to break into and rob than your neighbor’s?
Is using KRACK going to be the easiest way to break into your house? These guys are going to go after the easy targets. As a case in point, the previous owners of my house were a little paranoid and placed three locks on all the external doors. But the front door has glass panels on either side of the door and the back door has a big window basically at ground level. Adding locks to the door doesn’t buy much when someone can just kick in a window to break in.
However, if a motivated bad actor is deliberately targeting you they are more likely to utilize something like KRACK to break into your house. But they are also motiviated so even if KRACK isn’t used, they will find a way in. It is exceptionally difficult to defend against such an attacker. Also, think about it. If someone were to even know to deploy KRACK against you to gain entry into your house that would mean that they already know you are using home automation and enough about your automation to know that they will have a high likelihood of knowing that monitoring and HTTP injection attacks have a likelihood of success. This almost exclusively limits the attackers to motivated attackers who are deliberately targeting you personally.
So ultimately, while the impact can be high, the likelihood of someone using KRACK against you at this time to break into your house is really low. So the amount of effort you spend to defend against it should be proportional.
Yes but not as much as you would think. First of all, you have to have the OH server configured so the only way to communicate with it outside of localhost is HTTPS. Given the motivated and knowledgeable attacker from above, if it is possible for them to strip off the https given their man-in-the-middle position. They can also inject exploratory URLs to guess at and find your openHAB Item names. There is a lot that can be done to explore a network only through injecting commands and javascript in normal HTTP traffic.
This isn’t to say I disagree with you. There are all sorts of good reasons to only use HTTPS with OH. I just don’t want people to think that just using port 8443 is sufficient in and of itself.
A nice approach though it might be a bit overkill for a typical home environment. If you know how to set up vlans and a VPN in this way I say go for it but I wouldn’t push it for the less technical folks on the forum.
This is a really good idea and I wish OH came out of the box with an easier way to do this. “Something you have” is often stronger than “Something you know”. And if you add in authentication (i.e. username and password) you now have two-factor authentication.
If you were to post a tutorial on how you set this up I’m sure we can get it into the official docs.
I don’t know the esp8266 stack that well. If it will support encrypted MQTT connections your devices will be fine if you switch to that. If your esp8266s are doing something benign like just reporting temperatures and humidity you probably don’t need to do anything. If they are doing something important like reporting presance or connected to actuators you will probably want to use encrypted messaging.
I’m not sure where/how the esp8266s implement the wifi stack. If it is in hardware these devices will forever be vulnerable and encrypting the end-to-end traffic is your best bet. If it is in upgradable firmware then you will want to upgrade those who perform important actions or report important information.
[1] An old quote from Jim Butcher. “You don’t have to run faster than the bear to get away. You just have to run faster than the guy next to you.”
Some news regarding ESP8266:
Espressif has released security patches for their own ESP-SDK’s RTOS and NONOS:
https://www.kb.cert.org/vuls/id/CHEU-ARFFHX
esp8266 Arduino SDK integrate this fix in version 2.4 rc2:
Hope the final version will be available soon, but it’s a good first step to mitigate the risk.
And personnaly it’s not the motivated person that I fear the most, but the script kiddies that will try it once a KRACK-enabled kind of Kali will be available, not because they want, but just because they can.
And all this after I just redisigned the full network at home, with specific IOT vlan, filtered by proper firewall, and bridged to a Wireless connection, secured using WAP2 …
Script kiddies would fall into the category of casual bad actors. If you are in a congested apartment type environment, the script kiddies are indeed a threat. They can easily hide and attack multiple targets from their one location. The likelihood is pretty high that someone will attack. The risk reward for the bad actors is balanced in favor of the attacker so you would want to do more to protect your network.
If you are in suburbia or in a rural environment the likelihood that someone will be willing to and successful at WAR driving and deploying KRACK is pretty low. The risks are pretty high with neighborhood watches and the rewards are pretty low. So someone like that may need to do far less to protect their environment.
So like I said, everyone needs to calculate their own Risk and deploy mitigations as is appropriate.
It is good to see that Espressif is patching their devices. Hopefully soon the patches will filter down into all the various alternative firmwares.
Here is what I understand:
- This attack is targeted to clients so patching the router is not enough (it might not even be necessary if the router doesn’t act as a repeater).
- It will take some time to patch the wpa_supplicant on ALL clients (smartphones, PCs, IoT devices, …)
- In the meanwhile, hackers will develop tools to use this attack (Mathy Vanhoef didn’t release his tools yet)
So I am worried about the openHAB UI and openHAB app. If sslstrip transforms any https URL into http, I imagine it would work on the openHAB UI as I can access it both in https and http! And I imagine it would also work on the openHAB app…
What do you think?
I am near to that what Rich already said.
- Of course keeping things up to date (when possible) on long term is obvious.
- How urgent those updates are, can be different
It depends on what ecosystem (smart devices, intranet, everything else) you are running.
- When you already have security related stuff within your ecosystem this will be more urgent,
then for example in my ecosystem, where i have just some lights and some multimedia devices configured.
It depends on where you are running it, so where you are living, what are your surroundings.
- I would describe my surroundings as relative uncomplicated. I am really sure that the risk of for example script kiddies in my neighbourhood is really small since i know a bigger part of my neighbourhood.
This could be totally different for your case.
It depends on many other circumstances i think.
- Here I mean something like “i have also work stuff in my place here” or something like “Is my environment a profitable target for this attack”. Both of this examples can only be answered by the environment owner itself.
I understand it the same way.
One of the biggest router producers her in Germany (AVM → Fritz!Box) has announced to only update their repeater firmware due to the vulnerability for now, since the attack is targeted to clients.
Definitively and to complete this sentence:
There may or will be devices, that wont even get an upgrade since they have already reached their EOL.
→ Again something, that only you can determine for your environment.
They will for sure, but its on us to evaluate how risky this is for us.
My result:
- I will keep an eye on this topic, but i wont act headless now since i don’t classify my special case as a high risk environment.
- I will check my devices for updates, which i have done anyway since ever i think
- I will try to fig a bit more into some topics that have already been written down in this thread.
Especially reverse proxy is a topic, which i never paid attention too because of the effort it needs to dig into it.
Now I see things different and plan to read into this topic in the nearer future.
So far my 2 cents for this topic. 
It will be very useful if someone somewhere develops a tool to scan a network and identify any vulnerable devices…
How can we achieve that to avoid sslstrip rewriting URL’s?
You can be certain such a tool will be developed if it hasn’t already. I’m not sure it will get added to Nessus but you can bet it will be added to Metasploit and there will probably be tools added to Kali Linux. I wouldn’t be surprised if Fing develops something.
But you can bet that anything running a wifi stack older than a couple of weeks will be vulnerable unless they implemented the stack incorrectly (that is what is saving Mac and Windows, they did it wrong, ironic).
Host firewall that blocks connections to port 8080 from any IP that isn’t 127.0.0.1.
Very good idea! I didn’t think about it