Losing control over your “local” network environment

Say you built a small server – to play your audios or videos – and you want to easily and securely access it in your local network  It works great and you consider making a product out of it. Well – here’s the thing – there is no universal, convenient way for users to safely connect to your server – even in their local network. Let’s have a look at the situation, backgrounds and possible workarounds.

Your media server looks cool in it’s shiny case. Simply connect your browser to it and off you go. So – network cable plugged it, power it on, start up the browser and .. wait a minute .. what  am I supposed to type into the address bar? Bummer.

Problem 1: How to find a device in a local network?

Any device in a network – plugged in or wireless – needs an IP address to connect. It usually asks around and a service, called DHCP, assigns an IP number to the unit and it is ready to chat. This number is in no way static and can change after re-boots or even in between. But how do you know what number it currently uses? You don’t. It’s as simple as that. You can connect to your router to look at the dhcp-assignments and use this address, but again, that number can change. Some years ago (in 2002), engineers at Apple came up with the solution they called “Rendevouz” or “Bonjour” (also called “zeroconf” or “mdns”) and it works great. This service specifically identifies local resources with the “.local” ending. So – you simply type something like “mediaserver.local” into your browser’s address bar and boom – you are connected to your server.  Unless you use Windows or Linux. Or Google-Chrome with Android. Windows and Linux allow you to install some software (avahi on Linux) which is somewhat acceptable and it is rumored that Windows might provide this service by default in the near future. But if you have to rely on Android and it’s Google browser, you are out of luck.

Any work-around? Sure. You can set up a service with a known ip-address and have your media server tell this services what ip-address it is on (in your local network). This also could be an external name server. You could then connect with your browser to this external service which would redirect to the local address.  Disadvantage: You won’t be able to connect to your own media server in your own network if the Internet is not available. Because without access to the external server, you will no longer know the address to your local media server. Sounds ridiculous? It is.

Let’s say you managed to connect to your media server. Everything works fine now? That’s bad, because the connection is most likely not encrypted, the little “lock” icon doesn’t show, the address (url) doesn’t start with “https” and everything you type in (such as passwords) or downloads (such as audios) may be intercepted.

But that’s easily fixed. Just replace the “http://” with “https://” and everything should be fine now. But wait a minute: My browser now says that this is unsafe? I could have been hacked? What the hell? Bummer.

Problem 2: How securely transmit to or from a device in a local network?

In order to have encrypted communications going, (ssl/tls) the server and the browser need to negotiate using encryption certificates. Those certificates can be created by anyone without trouble. They need to be electronically signed and that signature is verified in the browser. Any browser has a number of trusted authorities in it’s database and if the signature comes from any of them, everything is hunky-dory. If a certificate has been signed by anybody else, the browser complains.

So usually, one would ask any of those “trusted” authorities to please sign the certificate of your media server. And they happily will. Unless the name of your media server ends in “.local”. Well .. what? Didn’t we just say that our local devices need to have a name ending in “.local” so that they can be found easily? Yes we did. So here’s the sad truth: One problem can be resolved by naming your resource something like “mediaserver.local” which explicitly prohibits the solution for our current problem. I love coincidences.

Why wont’ they sign a “local” name? Your thoughts are as good as mine. They did until around 2015. But they won’t anymore. If you ask them they come up with “can’t verify the authenticity of the name” which is true (because a “.local” name isn’t valid on the open Internet and they can’t look it up and verify you are the rightful owner). So somebody else also could have a signed certificate for “mediaserver.local” – but that’s not a bug – it’s a feature. Local domains are, by default and definition, only valid in local environments.  So who cares if one, two or a thousand people out there have “mediaserver.local” installed in their networks? Why do you have to proof anything in regard to the services running in your local environments?  This is nothing but a blatant attempt to force some kind of regulation on us even if we’re just deploying local devices in our local network.

Any work-around? Yes of course, but all are very awkward and/or require manual configuration by either the users or the admins of the network. Unless of course you go back to 1998 and not use encryption.

1. Have the users install you as a trusted authority in their browsers. You can make yourself an authority but this will only be trusted if your ‘root’ certificate has been installed. This is an (artificially constructed) complicated process and it may not even be available in all browsers. Example for Google Chrome.
2. Use an external server along the lines of Problem 1 . Let’s say you get a trusted “wild card” certificate for your own (real) domain mymediaserver.com. You could set up a name server that resolves any local domain into a valid “mediaserver.com” domain. Disadvantage: Without Internet, you won’t be able to connect to your local media server. See Problem 1.
3. Tell users to not mind the security warnings.
4. Don’t use encryption. It’s potentially unsafe but hey – no warnings.
5. Buy your own trusted “certificate authority” and do it your way. It may cost you a million bucks or so, but those are the times. Get over it and cough up the cash.
6. Don’t use the web. If you develop apps, you can suppress any warnings and errors coming from untrusted certificates. But this brings you right into the controlled realm of those who forced you to go that route in the first place.

Deploying a device within your local network and safely communicating with it should be easy. And if you have some basic understanding of your network environment, you can make it work without any problems or warnings.

However – if you want to make a product out of it – have it installed on several other locations as a consumer device, well – completely different story. It is 2018 and there’s no way to universally and safely discover a device in your local network and to safely communicate with it. Among other considerations, that’s a serious problem for the independent developments of home devices like “connected” home automation, local media distribution or local medical devices. Because as soon as you want to keep your (or your customers) local stuff .. well .. “private” .. you have other interests that are actively trying to nudge you into “their” ways, methods or environments.

In other words: Even a simple local device can not be found or securely communicated with unless you are accepting the fact that it (the local device) does not work without Internet availability.

Who’s in control ? Obviously .. it’s not you.

About the author:

Michaela Merz is an entrepreneur and first generation hacker. Her career started even before the Internet was available. She invented and developed a number of technologies now considered to be standard in modern web-environments. Among other things, she developed, founded, managed and sold Germany’s third largest Internet Online Service “germany.net” . She is very much active in the Internet business and  enjoys “hacking” modern technologies like block chain, IoT and mobile-, voice- and web-based services.