Use Cases and Requirements on HTTPS-enabled Local Network Servers

1. Introduction

This document describes use cases where browsers communicate with web-server-capable devices in local network via HTTP (https://) and/or WebSocket over TLS (wss://), as well as network, security, and privacy requirements on these usage.

Nowadays, a lot of devices like Internet-of-Things (IoT) devices and home gateways often have their own built-in HTTP server so that they can provide interfaces to configure and/or control them remotely via IPv4/IPv6 local network. Modern web browsers, however, usually regard those local servers as not trustworthy due to lack of authenticity of device’s identity. As a result, browsers would prevent trustworthy web sites from communicating to local network devices [MIXED-CONTENT] and prohibit web pages on the servers from accessing powerful features on browsers [SECURE-CONTEXTS].

Therefore, this document illustrates potential use cases that need access to local network servers and clarifies requirements for use of these servers.

2. Terminology

In this document, we refer to HTTPS as a scheme of communication allowed by the UA which uses TLS as a method for ensuring confidentiality of its content and identification/authentication of the counterpart of the communication. This means, the scope of the term HTTPS in this document is not limited to the https:// scheme but also includes WebSocket over TLS (wss://) and other schemes that operate in a similar way. Whenever there is a need to disambiguate so that the term specifies the https:// scheme only, the document will indicate so.

A UA (User Agent) is a web browser on a user’s PC, smartphone, tablet and so on, which is connected to a local network.

A device is in the same local network as the UA, capable of HTTPS server.

A web service is a service hosted on the internet and whose frontend is loaded on the UA, which accesses to the device with HTTPS or WSS on the local network.

A Web PKI certificate is a TLS server certificate that can chain up to a root CA (Certificate Authority) trusted by the UA (preinstalled on the UA).

A non-Web PKI certificate is a TLS server certificate that cannot chain up to a root CA, or a self-signed certificate.

A CA (merely called CA in this document) is a CA responsible for issuing the Web PKI certificates or non-Web PKI certificates. It is not restricted to a CA responsible only for issuing the Web PKI certificates.

A private CA is a CA responsible for issuing the non-Web PKI certificates.

3. Use cases

3.1. UC-1: Photo sharing between online services and home NAS devices

A user usually stores her private photos and videos in a home NAS device. She opens an online photo sharing service in a browser on her smartphone. The online service finds her home NAS device through the browser and shows her the NAS via a popup window. She selects the NAS and the browser shows her private photos in the NAS as well as the ones already stored in the online service. She then selects and posts some photos that she would like to share with her friends or, if she usually posts photos to the online service from her smartphone directly, she downloads the photos and posts them to the NAS device.

3.2. UC-2: Video streaming with cache storage in local network

A user has a video cache storage server for home to enjoy online video streaming services at UHDTV quality. When she opens the web site of one of the streaming services on her TV browser, the web page tries to find her cache storage and displays a list of storages via a popup window. She picks up one storage from the list to store caches of UHDTV video stream segments. After her permission, the streaming web application of the service can start prefetching or fetching UHDTV movies purchased or bookmarked by her and upload those segments to the storage. When she wants to watch one of the movies cached in the storage, the online service fetches the movie from the home storage to avoid consuming WAN traffic, and finally she can comfortably enjoy the movie.

3.3. UC-3: Web-based UI for home appliances (input/output constrained devices)

A user controls home appliances (e.g. air conditioner, microwave oven, refrigerator) with an online GUI service on the internet. The home appliances are designed natively to be used via the online GUI loaded in a browser on her smartphone or tablet. As with the use cases mentioned above, when she signs in to the online service, the service finds a home appliance through the browser. Under her approval, the service can be granted access privileges for the appliance and she can control it through the GUI service.

3.4. UC-4: Embedded system monitoring and controlling for display-capable devices

A field engineer of a digital signage service provider sets up an internet-capable display device. The engineer makes the device display a specific website as a signage content by using a browser on the device. After that, the website is monitoring the status of the embedded system (e.g. collecting logs, monitoring system resource utilization) continuously via the browser by using internal REST APIs provided by an internal web server (e.g. https://localhost) of the device. If the device provides the website with reboot functionality as one of the REST APIs, the service provider is able to not only check the health of the device, if necessary, but also reboot the device remotely via the website.

3.5. UC-5: Data analysis from analytical and measuring instruments in local network

An analytical and measuring instrument in local network outputs a large amount of raw data as the result of an experiment. An experimenter (a user of the instrument) signs in to a web-based analytical service provided by the vender of the instrument by using a browser in her PC. The experimenter analyzes the raw data by using the web service and the service fetches the raw data from the instrument directly in local network.

3.6. UC-6: Secure offline communication for home automation

A user wants to set up a new home device (e.g., a Wi-Fi access point/router, home automation gateway) in his/her home via its web interface. User typically opens a given URL for the device (e.g., https://home-router.local, or https://192.168.1.1) in a laptop or smart phone’s web browser. Since the new device does not have a valid web PKI certificate, the web browser displays a warning like “The connection is not secure” but provides an option to ask the user to approve the access or add the URL as an exception to the whitelist. Once user takes the action, the web browser treats the device as a trusted one and does not display the warning in subsequent attempts. Additionally, if the home device supports functionality such as, SSO (Single Sign-On) the user can use an identity (ID) provider’s account (e.g., Google, Facebook, and so on) to sign in the device’s web interface and provide the needed trust.

Similar secure access is required when a home gateway, which is typically controlling other home devices (e.g., door locks, security cameras), uses HTTPS for securely accepting commands via a remote server. However, when a home gateway happens to get temporarily disconnected from the internet, those home devices become inaccessible. In such scenarios, a local HTTPS communication from user’s local device (e.g., smart phone or a control device) is essential to control and operate the home devices directly through HTTPS connections over the local network.

3.7. UC-7: Companion Device for Broadcast Interactive Service

A user is watching a broadcast interactive service which is enhanced by a broadcaster’s web app running on the user agent of TV. The user hands a companion device, e.g. Smartphone, and launches a user agent with the Frontend page from the broadcaster web server. The Frontend page discovers the user-agent of TV and securely communicates with the broadcaster’s web application via the Web Socket Server on TV in order to provide GUI for the interactive broadcast service. Note that this use case is similar to the 2-UA of the Presentation API but the difference is that the broadcaster’s web application on TV is running on UA of TV in advance.

3.8. UC-8: Presenting with Projector at office

A user is attending a meeting at office (outside home). The user logs on an online document sharing service on PC and present his document file on the service with the Projector connected via local network. FrontEnd page on UA1 at PC initiates to launch 2nd frontend page on 2nd UA at the projector to let the 2nd frontend page present the document. Note that this use case is similar to 2-UA of Presentation API but the communication between 2-UA should be secured to prevent the MITM attack in the local network and also the regular WebSocket API is used for the communication, e.g. file transfer.

4. Requirements

This section outlines functional and non-functional requirements of HTTPS usage in local network represented in §3 Use cases.

Functional requirements consist of guarantee of device trustworthiness, device identification, alerting user and user consent, device discovery, and certificate management.

Non-functional requirements address security, privacy, availability, scalability, and user experience aspects of HTTPS usage in local network.

4.1. Functional Requirements

The functional requirements are listed below:

• Guarantee of Device Trustworthiness

• Device Identification

• Alerting User and User Consent

• Certificate Management

• Device Discovery

In the following, we elaborate on individual requirements as mentioned above.

4.1.1. REQ-1: Guarantee of Device Trustworthiness

The UA accesses the device with TLS (HTTPS or WSS) in all of the use cases envisioned so far. If the UA cannot trust the device’s TLS server certificate, the UA shows a warning message that means the device cannot be trusted. To avoid it, the device shall have a way to prove its trustworthiness to the UA.

Getting a Web PKI certificate is one of the ways to prove the device trustworthiness but the Web PKI certificate only works for globally unique domains, which must be registered in public DNS servers. For this scenario, the requirement is that

• The device has a Web PKI certificate and has a way to obtain it.

However, one may choose to use a memorable simple private domain name (e.g., “myprinter.local”) or may not want to register the device name to the public DNS server because of privacy concerns. In such scenarios, it is better not to use the Web PKI certificate for the device, however, the device and/or the UA shall have one of the following features or methods:

• REQ-1-1: The device has a way to obtain and use a non-Web PKI certificate and the UA has some out-of-band mechanisms to validate the certificate as a trusted one (e.g., the user and/or the web service’s approval).

• REQ-1-2: The device does not have a certificate but the UA has a way to validate and trust the device without any certificates (e.g., by using a PSK (pre-shared key) or an RPK (raw public key)), which is shared to the UA in a secure way.

4.1.2. REQ-2: Device Identification

In case that the user inputs the device URL to the address bar of the UA directly (§3.6 UC-6: Secure offline communication for home automation) or the UA shows the popup window to the user to get the user’s consent (§3.2 UC-2: Video streaming with cache storage in local network, §3.3 UC-3: Web-based UI for home appliances (input/output constrained devices)), the user may be able to recognize that the device URL displayed or input on the UA indicates the real device on the local network. In such cases, the device and/or the UA shall meet the following requirements:

• REQ-2-1: The device identifier (domain name) should be easy to remember and short enough but not to recognize as fraudulent by anti-phishing.

• REQ-2-2: The device and the UA should have a pairing method by using the device interface (e.g., pushing a specific button on the device to start the pairing, showing the PIN code for the pairing on the device’s display).

4.1.3. REQ-3: Alerting User and User Consent

The frontend of the web service loaded on the UA should not be able to access the device without an explicit approval from the user especially during its first time access. This is essential in cases where the device is not capable of using a Web PKI certificate. In such cases, the UA will possibly use an alternative identifier (e.g., non-Web PKI certificate, PSK, RPK) but it must not be trusted without the user’s consent. Therefore, considering the UA shall meet the following requirement:

• REQ-3-1: When the frontend of the web service requests the UA to access the device in local network, the UA shall show a popup window to obtain the user’s consent and shall permit the access only if the user approve the access.

• REQ-3-2: When the device does not use a Web PKI certificate for HTTPS communication, the UA shall have a way to obtain user’s consent to trust an alternative identifier (e.g., non-Web PKI certificate, PSK, RPK).

4.1.4. REQ-4: Certificate Management

When the device obtains a TLS server certificate for HTTPS communication, the CA, UA and the device shall meet the following requirements:

• REQ-4-1: The CA that issues certificates for devices shall be able to revoke the certificates.

• REQ-4-2: The UA shall be able to detect the revocation of the device’s certificate.

• REQ-4-3: The device shall be able to refresh the certificate at any time.

4.1.5. REQ-5: Device Discovery (optional)

As described in §3.2 UC-2: Video streaming with cache storage in local network and §3.3 UC-3: Web-based UI for home appliances (input/output constrained devices), when the web service does not know the device URL in advance, the device needs to be discovered. That means, if device discovery were to be implemented, the process must meet the following requirements:

• REQ-5-1: The UA shall be able to discover the presence of devices in the same local network.

• REQ-5-2: The UA shall be able to obtain the endpoint URL of the device that has the scheme https:// or wss://.

• REQ-5-3: When the UA finds multiple devices, the UA shall be able to present the selector interface to display the list of the devices and allow the user to select one specific device.

4.2. Non-Functional Requirements

The non-functional requirements are listed below:

• Security

• Privacy

• Availability

• Scalability

• User Experience

4.2.1. REQ-6: Security

It is essential to take care of the following security considerations:

• REQ-6-1: If the device uses a TLS server certificate for HTTPS communication, the certificate issuance and renewal steps shall prevent passive network eavesdroppers from learning information related to the identification or certificate exchanged among the system components (the CA, the device, the UA and the web service).

• REQ-6-2: If the device uses a TLS server certificate for HTTPS communication, the certificate issuance and renewal steps shall prevent active network attackers from impersonating a device and observing or altering data intended for the CA or for the UA.

• REQ-6-3: If the device does not use a TLS server certificate, alternate steps for the UA to initiate a TLS session to the device (e.g., sharing and using a PSK or a RPK) shall prevent passive network eavesdroppers from getting the PSK or the private key of the RPK.

• REQ-6-4: If the device does not use a TLS server certificate, alternate steps for the UA to initiate a TLS session to the device (e.g., sharing and using a PSK or a RPK) shall prevent active network attackers from impersonating a device and observing or altering the keys for the UA.

• REQ-6-5: Device identification (e.g., the pairing method mentioned above) shall prevent passive network eavesdroppers from learning information related to identification.

• REQ-6-6: Device identification and device discovery (if the UA supports it) shall prevent active network attackers from impersonating a device and observing or altering data intended for the CA or for the UA.

4.2.2. REQ-7: Privacy

The user privacy shall be preserved against the web service especially when the user allows the frontend of the web service to access the device for private use. In such scenarios, the UA and the device shall meet the following requirements:

• REQ-7-1: When the UA supports device discovery functionality mentioned above and the UA finds multiple devices, UA shall disclose only one device selected by the user.

• REQ-7-2: To avoid disclosing the device name and the IP address to the internet, the device should be able to use a private domain name.

• REQ-7-3: To avoid user tracking by means of using the device, the evice identifier (e.g., a TLS server certificate for the device) should not be static and preinstalled. The device should be capable of obtaining the TLS server certificate dynamically for HTTPS communication during commissioning.

4.2.3. REQ-8: Availability

In scenarios (e.g., §3.6 UC-6: Secure offline communication for home automation) when the device and the UA gets temporarily disconnected from the internet, the UA and the device should be able to communicate with each other on the local network. Therefore, the device and the local network system shall meet the following requirements:

• REQ-8-1: When the device has a private domain name (e.g., *.local, *.home.arpa) or a private IP address, a private CA shall be able to issue a TLS server certificate for the device.

• REQ-8-2: If the device has a public domain name, the local network system should have a way to help the UA with resolving the public domain name without an internet connection (e.g., without querying a public DNS server).

4.2.4. REQ-9: Scalability

If all IoT devices started using Web PKI certificates for HTTPS communication, the number of certificates required will be significantly larger than the total number of certificates exists today for public web servers. Therefore, following exemption may be required:

• REQ-9-1: If the device uses a Web PKI certificate for HTTPS communication, the CA should be exempt to preserve CT (certificate transparency) logs for the devices.

4.2.5. REQ-10: User Experience

While the user interaction is required in certain scenarios, it should not be a hindrance to providing a better user experience. Following requirements should be considered:

• REQ-10-1: The UA should minimize user’s interaction for device identification as much as possible.

• REQ-10-2: If the device uses a TLS server certificate for HTTPS communication, the procedure of certificate grant and issuance and renewal should be automated as much as possible so that the users' interaction can be greatly minimized.