Skip to main content

SUIB Problem Summary

Anyone who has tried to use a browser to configure or manage a device on their home network will be familiar with the following situation. Firstly, one needs to know the device’s local IP address, which is used in lieu of a hostname in the URL. Then, one typically needs to use the unencrypted version of HTTP, i.e. HTTP rather than HTTPS, potentially exposing passwords and other sensitive information to eavesdropping. If one tries to use HTTPS, then the browser will most likely display a dire-sounding warning saying that the connection is not private and attackers might be trying to steal information. Someone with knowledge of networking and security will understand what this really means and make an informed judgement about whether to proceed, but an average home user will either be scared off or will unlearn normally safe guidance about not interacting with a web site unless the closed padlock is displayed in the browser’s address bar.

So, what is the problem? Consider what happens during normal Internet browsing over HTTPS. When a URL is entered or a link clicked, the browser needs to work out where to send the request. It extracts the contents of the hostname field from the URL. If the result is an IP address, this can be used directly, otherwise if it is a DNS-compliant domain name, the browser uses DNS to look up the corresponding address. To prove its legitimacy, the web site to which the request is sent returns its TLS certificate. The browser checks that the certificate is valid, that the signature can be traced back to a root of trust the browsers recognises, and that the domain information is consistent with the hostname in the request. If all this is good, a TLS connection is initiated. As part of the set-up phase, the web server demonstrates possession of the secret key corresponding to the public key disclosed in the certificate.

Why can this not happen on a home network? Firstly, home networks almost always use private IPv4 address space, most commonly, This means that large numbers of unrelated devices around the world will have the same local IP address. Consequently, certificates citing such addresses would have little or no value unless local in scope, i.e. issued by a Certificate Authority (CA) that is trusted only within the local network. Furthermore, IP addresses on home networks are subject to change — they are mostly issued dynamically and IoT devices are often mobile — so even on a local basis, certificate management would be challenging. The situation is a little better if devices are given (fully qualified) hostnames against which certificates are issued. Hostname-to-local-address mappings can be registered with the DNS system, but the IP addresses returned would only make sense in the context of particular local networks. For example, it could work fine for fixed devices with static IP addresses, but the IP address would only correspond to the target device if the browser and the device were on the same local network.

What is needed is a local means of address resolution. One already exists in the form of Multicast DNS (mDNS for short). To use mDNS, a host wishing to know an IP address on the local network sends a request to resolve the target name to other hosts via the link-local multicast address. Hosts able to answer the query do so, normally again using multicast so that all hosts may update their caches of name-address records. One restriction is that the hostname must have only two elements separated by a dot, the second of which is “local” (e.g. MyPrinter.local). The mDNS name will not be unique and due to the rules against signing certificates for local names, browsers will not trust these certificates.

To summarise, the main challenges that a solution will need to address include:

  • Means of assigning names to devices and of avoiding and resolving naming conflicts. One option is for manufacturers to assign persistent names from within their own namespace to devices before delivery. Names do not necessarily have to be unique, though this may be desirable. If multiple devices have the same name, they should be in some sense equivalent (it is perfectly legal and indeed normal for DNS queries to return multiple IP addresses). The same name could be represented in different forms, for example, a conventional fully-qualified domain name (FQDN), and a two-element mDNS name where the first element is a hash of the FQDN, and the second element is “local”.

  • Means of creating, provisioning, revoking and verifying certificates that enable devices to prove ownership of a name. The body issuing the certificate should derive its authority from a recognised root of trust. In the case of manufacturer-assigned persistent names, it makes sense for the manufacturer also to operate as a CA and to pre-provision the devices with certificates. Note that it is possible for a certificate to list alternative names as well as a main ‘common’ name.

  • Local means of resolving device names to local addresses, based on mDNS, DNS or some other mechanism.

  • Browser authors should be encouraged to make their warning messages concerning missing, self-signed, etc. certificates more informative and context-specific, especially when interacting with devices on the same local network. Device manufacturers should be encouraged to provide for HTTPS access by pre-provisioning devices with certificates even if they are not recognised CAs, as the protection offered by encryption is valuable even if the identity of the device cannot be confirmed.

In order to identify an optimal solution, the following sections explore some of these background concepts in greater depth.

  • Addressing: How is a device connected to the network (e.g. ethernet), how is it addressable (e.g. RFC1918 IPv4) and how does it implement name resolution (e.g. DNS or mDNS) The physical and logical addressing are a means for a browser to identify the local scope. The IP and DNS names are relevant because they are used by the browser to locate the device and in TLS certificates these are used as identifiers for the device. CA/Browser Forum uses the term "internal names" for IP and DNS names used in a local scope.

  • Browser: Current browsers following CA/Browser Forum requirements show a padlock icon for certificates that are signed by a Root Certification Authority (CA), and generic security warnings are displayed for certificates that are not verified. How can a secure connection be established to local web servers and does this require a change in the browser?

  • Certificates: For public Internet certificates the browser behaviour follows clearly defined TLS certificate management principles. For the local web server scenario, what changes are needed to make the certificate chain work?

  • Device Onboarding: How do the IoT devices get onboarded on the network and how does the browser discover connectable IoT devices?