Securing the Internet of Things? How about securing the Internet first?

The non-profit organization I am part of, aykit, recently released an Android Version and it’s sources for ownCloud Notes. Having ownCloud Notes, you add and edit notes using your ownCloud server. This is quite convenient and a good replacement for proprietary tools provided by google, Apple and others.

After releasing our app, we got feedback regarding our lack of support for http. Yes, it is true, we are only supporting https connections at the moment. To be frank, most of the tools we use in our daily work are only accessible through https as well. This article is about why we think this should be the norm.

Securing the Internet of Things

At the moment, articles about securing the Internet of Things are released on a daily basis. Yes, the Internet of Things needs to be secure. It needs to be, as it affects very central artefacts of our lives. Think about a car being hacked, not doing what you need it to do, e.g. accellerating when you are hitting the brakes. Or the nearby power station. If the U.S. has been able to cause havok in Iran, who says the same will not happen in other parts of the world?

It is true: We live in a world, where things are controlled by microchips and, worse than that, where those microchips can be accessed from the outside. I have no idea if we need it to be like that. Hype says we do.

Securing the Internet

What’s strange is the focus on the Internet of Things. The Internet of Things is the very same Internet all other computers are connected to. Your server, your Iphone and your Personal Computer (That includes your mac too. Cry if you must): They are all part of “The Internet”. They can be used, and misused.

Think of a web connected fridge. You configured your fridge with all ports open (I have no idea what ports such a fridge uses. Let’s say 22, 8080 and 443) and available to devices on the LAN. This is really convenient. If you are at home you just need to open your browser and look at your food’s status. To check the status from abroad, you establish a VPN. Great. This should be secure, shouldn’t it?

And now here you are. Your “Internet of Things” may be secure, but your router isn’t. Congratulations, you have a problem.

Securing the Internet is securing the applications

Fact is, we, the common people, don’t need to secure Layer 1, that is what the big players have to do for us. We need to watch all other Layers, Layer 7 being the most devious as everyone is tinkering with it. So that’s where we find ourselves when discussing enforced usage of TLS. Since Heartbleed, the very last of us knows there’s a problem. A problem that needs fixes.

Not allowing http-connections may be one of them. There is no need for http nowadays. Modern computers are bored by handling TLS connections. The only “benefit” of http over https is it’s suitability for even the laziest of all system administrators. Let’s face it: Setting up self-signed certificates is a very basic task for everyone involved in computer maintenance on an enterprise level. And as ownCloud needs to be setup by someone with at least basic knowledge of Apache2 (or whatever webserver he/she uses), reading the enclosed Apache2 SSL Manual shouldn’t be too much to ask.

This is especially true for all sensitive data. In my opinion, e-mail and all other personal data is really really sensitive. It should not be shared with the world. Connecting via http is exactly this: sharing all your data with everyone. It’s like telling your doctor’s news someone at the very end of a restaurant. There may be news like your new-born baby that should be shared. But I am convinced you wouldn’t share yourself being tested positive for cancer with everyone.

But the user!

During the discussion, some people posted enforcing TLS is far off a user centric design. But hey, I love user centric designs! Every software I accompany needs to be user centric. Users want shiny edges? They get shiny edges! Users want blurry faces? They get blurry faces! Users want the app to be easy, so please get rid of the warning dialogue? They get…. wait what?!

That’s when we all need to say: No! We will not sacrifice security for the sake of an easier-to-use interface. No, we won’t serve a warning dialogue providing options. And you know why? Because this dialogue is meant to be clicked away.

Think of Windows in it’s early days, giving us a warning dialogue every five minutes. What did we learn? We learnt to click it away!

Warning: Blue button
OK
Warning: I close this window.
OK
Warning: this thing explodes if
OK

Warning dialogue? Didn’t read!

Yes, we released an app not accepting insecure URLs. And do you know how we feel? We feel awsome. We feel as if we did something right this time. Our app may have some issues and it may not be perfect, but this little thing? This little thing not allowing unsecured connections? It feels like one of the best choices we ever made.

Everyone who wants us delivering user-centric design: Yes, we will do that. But if it threatens Internet security, we just won’t deliver. We will say no and we will force lazy administrators to get off their asses and do what they are supposed to do: Securing the client’s environment like a boss. If a ton of good system administrators do it, so can you.

Future

Will we keep this up? We don’t know. The version released today does not support insecure requests. And we won’t implement the approaches suggested on github so far. The most preferrable solution to date is adding an extra option that switches “insecurity” on and gives you a warning dialogue so scary you’ll never enable it again.

Or we just skip http. It’s 2014. Insecure connections are a thing of the past. They may not go away on static websites like aykit.org but they sure need to go away at only the slightest chance exchanged data might be private.