Approaches to Achieving HTTPS in Local Network

1. Introduction

By tradition, diverse kinds of connected devices have HTTP server functionality to provide their users with web-based UIs. Since such kind of devices in local network cannot easily get valid server certificates, most of the devices have to use non-secure HTTP.

On the other hand, recently, using HTTPS is getting popular rapidly on the internet due to various efforts to make the internet secure, such as [LETS-ENCRYPT]. Following the trend, browsers' security policies have been enhanced gradually to deprecate insecure HTTP. For example, new features on browsers are supposed to be restricted only to [SECURE-CONTEXTS].

As the result, browsers came to show negative security indicators when the devices are accessed by their users. Browsers also prevent web applications in secure contexts from accessing and collaborating with the devices. In addition, the devices cannot use powerful features ([SECURE-CONTEXTS]) on their web-based UIs. The local devices have been marginalized in the current secure web.

In this document, we propose comprehensive technical approaches to address the problem on using HTTPS in local network. All of the approaches in this document are not feasible on existing web standards for the browser and/or related communication protocols and systems. Therefore, this document describes not only the explanation of each approach itself but also related requirements for the browser, and required standardization activities on the communication protocols and systems.

The purpose of this document is to initiate discussions and receive feedbacks from the W3C members especially from the browser vendors and web developers. Authors of this document are aware that the proposed approaches might not be based on the current design and security policies of the browser implementations but certainly hope that the community will update these policies to cater the need for new emerging markets, such as Internet of Things (IoT).

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.

In addtion, this document uses the following terms as defined here:

A local network is a network defined in §3.2 Target Local Networks

A UA (User Agent) is a 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 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 public CA is a CA responsible for issuing the Web PKI certificates.

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

3. Scope

The approaches proposed in §5 Technical Approaches are based on the use cases and the requirements defined in [HTTPSLOCAL-USECASES].

3.1. Target Devices

To focus on the problem on using HTTPS in local network, approaches for publicly accessbile devices are out of scope. Actually, it is easy for such kind of devices to get Web PKI certificates so there are few technical challenges on browser implementations and related standardization activities. Therefore, this document does not contain the approaches for the publicly accessible devices as §5 Technical Approaches but as §4 Existing Solutions.

3.2. Target Local Networks

Based on [HTTPSLOCAL-USECASES], we regard following types of network as local network:

• home network

  • Related use cases: [UC-1], [UC-2], [UC-3], [UC-6], [UC-7]

• intra-company network (includes factory network, building network, etc.)

  • Related use cases: [UC-5], [UC-8]

• intra-machine(intra-UA) network (uses loopback addresses, etc.)

  • Related use cases: [UC-4]

In aspect of IP address spaces, local networks in this document can be defined as the networks that use following address spaces or prefixes:

• IPv4 private address space defined in [RFC1918].

• IPv4 link-local space defined in [RFC3927].

• IPv4 loopback space defined in [RFC1122].

• IPv6 unique local address prefix defined in [RFC4193].

• IPv6 link-local prefix defined in [RFC4191].

• IPv6 loopback address defined in [RFC4191].

3.3. Target Access Patterns

In general, we can categorize the use cases listed in [HTTPSLOCAL-USECASES] into two device access patterns principle for local HTTPS. They are as follows:

• Normal access pattern: the device has web contents and a user types the address of the device (e.g., https://device.local) on the UA directly and receives the contents.

  • Related use cases: [UC-6]

• Cross-origin access pattern: the device has API endpoints and a web frontend loaded on a UA from the internet (hereafter, simply called ‘web service’) accesses the APIs with a browser API (e.g., [FETCH]) and receives the contents.

  • Related use cases: [UC-1], [UC-2], [UC-3], [UC-4], [UC-5], [UC-6], [UC-7], [UC-8]

All approaches proposed in this document are based on either one or both of the access patterns.

4. Existing Solutions

Before providing the list of the technical approaches, we’d like to walk through existing solutions.

4.1. Web PKI based Solutions

When a device is publicly accessible, the device can get a Web PKI certificate from a public CA and use it on HTTPS communications with UAs. However, in this case, the device's domain name must be globally unique (e.g., device-id.device-vendor.com) because public CA cannot issue certificates for local domains such as .local([RFC6762]) or .home.arpa ([RFC8375]) as described in [CABFORUM-GUIDANCE-DEPRECATED-INTERNAL-NAMES].

Example current industry best practices of this solution are Mozilla’s [WEBTHINGS-GATEWAY] and [PLEX].

While these solutions are deployed and fits well in some use cases, they cannot work in scenarios where domains are for example, device.local or device.home.arpa. Moreover, the access to local devices in the first place is an important issue (we understand that this issue can be mitigated by preconfiguring the gateway router/proxy but these settings are difficult to be made available in scenarios such as home networks). The other issue is resolving the domain name when there is no internet access. Finally, the number of required public CAs is significantly larger than other use cases due to the vast nature of IoT devices.

4.2. Non-Web PKI based Solutions

Installing non-Web PKI certificates (e.g., self-signed certificates) into a UA as a trusted one manually is a widely used solution. Manually installing non-Web PKI certificates (e.g., self-signed certificates) onto a UA as a trusted certificate is a widely used solution. However, manual operation can make it prone to user error.

5. Technical Approaches

In this section, we describe technical approaches for using HTTPS in local network except for using normal Web PKI certificates, and complicated (and maybe dangerous) manual operations referred in §4 Existing Solutions.

Each approach defined in the following sections is categorized based on the first class requirement, [REQ-1]: Guarantee of Device Trustworthiness.

5.1. Web PKI based Approaches

5.1.1. APPROACH-1: Using technically Constrained Certificates

This section’s description is written for Web PKI certificates with Server-auth Extended Key Usage.

Public CAs need to verify the DNS name of a certificate at the time of issuance of Web PKI certificates with Server-auth Extended Key Usage, following CA/BForum Baseline Requirement [CAB-BR]. However, a public CA cannot verify a local network’s local IP address. So public CAs cannot generally issue certificates for devices, barring an exception, which is technically constrained certificates.

Technically constrained intermediate CA

The term "technically constrained intermediate CA" in CABForum’s baseline Requirement might be confusing. There is a term "technically constrained" in the [CAB-BR], and "name constraint" is one of requirements for Certificates with "EKU = server-auth" to be "technically constrained" If EE (End Entity) certificates will be technically constrained, issuing public CA do not need to verify the DNS name at the time of issuance, and that public CA can publish certificates for devices.

Name constraints seem to working well in many browsers now [BETTER-TLS]. The mechanism of name constraint is well explained by Netflix [BETTER-TLS], so we briefly explain how it works in the next paragraph.

How technically constrained intermediate CA issues Web PKI certificates

We assume that the device vendor has to have control over ".camera.example.com," for example.

A public CA validates the device vendor’s control over .camera.example.com, and issues a name-constraint intermediate CA cert. That intermediate CA is technically constrained, and only able to issue valid certificates with .camera.example.com . Since the vendor is controlling .camera.example.com and .camera.example.com has been validated, validation of "device1.camera.example.com" can be skipped at that time, and that public CA would able to issue an EE certificate for device1.camera.example.com. After transporting that certificate to a device somehow, that device can use a Web PKI certificate.

Possible use case

Here, we assume the DNS server of ".camera.example.com" has a record of device and its local IP(e.g 192.168.2.100) with some mechanism (1). So, that DNS server can reply with local IP address. The browser can then get the IP address of device (right hand side solid triangle lines).

Then browser can have TLS connection with the device, which has a local ipaddress. The device vendor needs to maintain the security of the ".camera.example.com" network.

5.1.1.1. Dependency on other SDOs

• Mechanism to install EE certs onto devices and update them at least once every other year[CAB-BR].

• Attestation mechanism to confirm that the devices are a product of a specific device vender.

• Revocation mechanism for devices with unauthorized modification

5.2. Non-Web PKI based Approaches

In this section, we describe three technical approaches for communications between a UA and a local server that has private domain names.

NOTE: For the following discussions, we use device.local as an example of a domain name of a device. Of course, other local domain names (e.g., device.home.arpa) are applicable name which can be resolved but the name resolution methods should not be restricted only to mDNS ([RFC6762]).

5.2.1. APPROACH-2: Using Shared Secret

This approach is based on the user grant and the use of shared password in which PAKE (e.g., [SPAKE2], dragonfly [RFC7664], J-PAKE [RFC8236]) is used for the establishment of a TLS session between the UA and the device.

NOTE: It is worthwhile to mention that J-PAKE has already been implemented in [MBED-TLS] and the use of [SPAKE2] has been discussed in [W3C-SECOND-SCREEN-WG].

5.2.1.1. Device Access Flow

This approach can be realized on both of the access patterns mentioned in §3.3 Target Access Patterns.

Normal Access Pattern

1. When a user inputs a device URL (https://device.local) to the address bar of the UA directly, the UA allows the access only if the user grants the access through the UI shown in the figure below.

   

2. The UI will be displayed when the device URL has local domain name and the underlying TLS handshake detects the device supports a PAKE-based cipher suite (e.g., [SPAKE2], [RFC8492], [EC-JPAKE], [PAKE-WITH-TLS1.3]).

3. To make sure that the device.local displayed on the pop-up window is really the same as the domain name of the device which the user intends to grant the access to, user inserts either a PIN or password through the pop-up window.

4. When the PIN or password is correct, the TLS handshake will be completed successfully and the user can get a web UI of the device without any negative security indicators.

The above flow can be achieved by extending the UI with adding the cipher suites in the browser. This will enable binding the displayed domain name to the physical device.

Cross-Origin Access Pattern

1. When a web service (e.g., https://device-user.example.com) accesses the device via the UA. The UA allows the access only if the user grants the access through the UI shown in the figure below.

   

2. The UI will be displayed when the underlying [FETCH] API is called for the access to the device that has a private domain name and successfully performs a TLS handshake using a PAKE-based cipher suite.

3. Subsequent flow is the same as the normal access pattern described above.

As with the normal access pattern flow mentioned above, this flow can be achieved by extending the UI with adding the PAKE-based cipher suites in the browser.

5.2.1.2. Skipping user consent

This approach might have to have a way to mitigate the PIN or password entry for subsequent TLS sessions, or the user has to input it every time the user uses the device.

To skip user consent, a specific method on how to bind the ununique private domain name (device.local) to the TLS session established by using PAKE needs to be defined to distinguish devices which have the same names as mentioned in [HTTPS-FOR-LOCAL-DOMAINS].

As for this PAKE-based approach, for example, using device ‘private domain name + fingerprint in self-signed certificate’ as the TLS server identifier (which is defined in [EC-JPAKE] can be considered as one of the candidate approaches. The use of self-signed certificate after the first PAKE based TLS session needs to be defined as well.

To skip user consent on the normal access pattern, the browser has to manage the addtional element (e.g., fingerprint in the self-signed certificate) in context with the origin of the device internally.

On the other hand, as for the cross-origin access pattern, [FETCH]] API might have to have a way to return the fingerprint in the self-signed certficate provided by the device as the result of the TLS handshake with the PAKE-based cipher suite, and also have a way to use the fingerprint as demonstrated below.

fetch("https://device.local/stuff", {
  // The following extension might be available only to private domain names.
  tlsExtension: {
    // type of the TLS extension.
    type: "pake",
    // base64-encoded SPKI of the certificate or its fingerprint.
    //     this is an optional argument for subsequent TLS sessions
    //     to identify the local server and to omit user approval.
    pinnedIdentity: "8fwpbctkMAq2x73orFsOXMruxWnmFSyhXioQmclhJ5L="}});

5.2.1.3. Browser Requirements

The requirements for browsers can be summarized as follows:

• Support additional cipher suites for PAKE (e.g., [SPAKE2], [RFC8492], [EC-JPAKE], [PAKE-WITH-TLS1.3]).

• Implement the pop-up window for PIN/Password input.

• Support a method to distinguish devices which have the same names.

• Extend [FETCH] API to support the method to distinguish devices as demonstrated in this section.

• Support a method to use a self-signed certificate after the first PAKE-based TLS session to skip user consent every time the TLS handshake happens.

5.2.1.4. Dependency on other SDOs

This approach will require work and collaboration with the IETF.

• [SPAKE2], [EC-JPAKE] and [PAKE-WITH-TLS1.3] were individual submissions and they are currently expired. If W3C embraces this approach, the work needs to resumed and completed.

• A method to bind a private domain name to a PAKE-based TLS session needs to be specified and standardized.

5.2.2. APPROACH-3: Using Application Layer Access Token

In §5.2.1 APPROACH-2: Using Shared Secret, there is no trust anchor that can guarantee the authenticity of devices and it is difficult for users to find whether the device is a legitimate one. From the standpoint of web services, it is often argued whether a server authentication should be delegated to a user’s judgement.

This approach resolves the problem by introducing an [IETF-ACE-WG] and [IETF-OAUTH-WG] based AS (Authorization Server) as an authority of the device into the local HTTPS system as shown below.

The ACE components have the following relationships:

• The device, which is regarded as an RS (Resource Server) in the context of ACE, has a trust relationship with the AS. In our assumption, the AS is configured by the device manufacturer.

• The web server, which is regarded as a client in the context of ACE, has been registered to the AS in advance and has a trust relationship with it.

• The user, which is regarded as a Resource Owner in the context of ACE, has an account for the AS and the ownership information to device has been registered to the AS in advance.

Under the above relationships, the client (web service) can get an access token to access the device based on user’s approval. At this time, the client can also get the RS information that includes an URI and an RPK(Raw Public Key)([RFC7250]) or self-signed certificate of the device (step (B) as shown in above figure). Since the existing browsers do not permit the access to the device with the access token (step (C) in above figure), browser API and related UI need to be extended to enable the client to access the device only when the client provides the UA with the RS information (a self-signed certificate or RPK) as a trusted one.

5.2.2.1. Cross-Origin Access Pattern

The RS information can be sent to the UA as an extended parameter of [FETCH] API as follows:

// When RS Information includes a RPK, 
fetch("https://device.local/stuff", {
  tlsExtension: {
    // type of the TLS extension.
    type: "rpk",
    // a base64-encoded raw public key or its fingerprint.
    pinnedIdentity: "8fwpbctkMAq2x73orFsOXMruxWnmFSyhXioQmclhJ5L="}});

// When RS Informatin includes a self-signed certificate, 
fetch("https://device.local/stuff", {
  tlsExtension: {
    // type of the TLS extension.
    //     'pkix' might be a default value that can be omitted.
    type: "pkix",
    // a base64-encoded SPKI of the certificate or its fingerprint
    pinnedIdentity: "8fwpbctkMAq2x73orFsOXMruxWnmFSyhXioQmclhJ5L="}});

When the [FETCH] API above is called, the UA shows a following pop-up window.

As the result, HTTPS accesses from the web service to the device are achieved by the UA based on the trust relationship between the client and the AS (and the device) and with user’s explicit approval.

In addition, when the trust relationship between AS and the devices is built on attestation keys in TPM (Trusted Platform Module) on the devices, the authenticity of the devices can be enhanced. The use of the attestation keys is applicable to §5.2.3 APPROACH-4: Using Device Authority-Issued Certificate as well.

5.2.2.2. Browser Requirements

The requirements for browsers can be summarized as follows:

• Support additional parameters of [FETCH] API mentioned above.

• Support a TLS certificate type and extensions for using RPK.

• Implement the pop-up window shown above.

5.2.2.3. Dependency on other SDOs

This approach will require work and collaboration with the IETF.

• HTTPS profile for ACE (or extensions for OAuth): Since ACE is based on CoAP/OSCORE, it is necessary to define either a HTTPS profile for ACE or an extension to COAP/OSCORE under the assumption that the RSs are distributed and deployed in local network.

5.2.3. APPROACH-4: Using Device Authority-Issued Certificate

In this approach, the web service trusts a vendor (device authority) issued private certificate and asks the UA to pin the certificate as a trusted one (only in the web service’s secure context) based on user grant. The trust can be built as an extension to §5.2.2 APPROACH-3: Using Application Layer Access Token in which AS has a private CA role and the web service trusts a private CA issued certificate based either on a pre-registered relationship with the CA and AS or by some other means.

This approach can be realized by extending the browser API and related UI in a similar way as shown in §5.2.2 APPROACH-3: Using Application Layer Access Token. Specifically, by extending the [FETCH] API as described below, it enables web services to provide the browsers with private CA certificates or private CA issued certificates as trusted ones.

fetch("https://device.local/stuff", {
  tlsExtension: {
    // type of the TLS extension.
    //     'pkix' might be a default value that can be omitted.
    type: "pkix",
    // base64-encoded SPKI of the vendor CA cert or its fingerprint 
    pinnedIdentity: "8fwpbctkMAq2x73orFsOXMruxWnmFSyhXioQmclhJ5L="}});

Similar to earlier approaches, the UA shows a following pop-up window when the [FETCH] API above is called.

For this approach, we argue that the framework on which a device vendor validates domain names of the devices and guarantees the authenticity of them would be useful even if the names are local names. A domain-validated certificate can be issued by using the OOB (Out-of-Band) challenge as defined in the earlier draft of ACME([ACME-DRAFT-8]). This was also discussed in [TPAC-2017-breakout-session].

The challenge, which is the access to ‘https://device.local/.well-known/acme-challenge/{token}’, is executed by the ACME server’s frontend loaded on a browser that can communicate with the device in a local network. Although the challenge through the UA has some advantages (e.g., it can be based on a user grant, there is no need to change the firewall settings), it requires a [FETCH] API extension for §5.2.1 APPROACH-2: Using Shared Secret that enables the access to the device based on self-signed certificates or RPKs.

It is important to note that there are other industry efforts on similar concepts as vendor-issued certificate (hereafter, private CA issued certificate). For example, [IEEE802.1AR] defines IDevID and LDevID that are device identifiers issued by the device manufacturers, and it seems that [PKI-CERTIFICATE-IDENTIFIER-FORMAT-FOR-DEVICES] tries to make the device identifiers be available on the Web PKI. In addition, [IETF-ANIMA-WG] has discussed the way to issue an LDevID autonomously based on an IDevID. Therefore, we propose that the vendor-issued certificate should be regarded as an accepted mechanism that should be leveraged by the W3C community.

5.2.3.1. Browser Requirements

The requirements for browsers can be summarized as follows:

• Support additional parameters of [FETCH] API mentioned above.

• Implement the pop-up window shown above.

5.2.3.2. Dependency on other SDOs

This approach will require work and collaboration with the IETF.

• [PKI-CERTIFICATE-IDENTIFIER-FORMAT-FOR-DEVICES] is currently an individual submission yet.

• The ACME extension as described above.

5.3. Pros and Cons of the Approaches

NOTE: Write a table that shows relations between the requirements (REQ-x) and the approaches (APPROACH-x).

5.3.1. APPROACH-1

5.3.2. APPROACH-2

• Pros

  • There is no need for manufactures to deploy and maintain their own servers (AS and/or CA) on the internet.

  • It is applicable to both access patterns use cases.

  • There is no need to extend the Fetch API.

• Cons

  • There is no trust anchor for web services to trust the devices and their domain names.

  • A user has to input a PIN /password, or a device has to support a secondary communication channel (e.g., BLE, NFC).

  • Web browsers need to support PAKE-based cipher suites.

5.3.3. APPROACH-3

• Pros

  • Web services can trust devices as far as they can trust AS for the devices.

  • If a device can get web service information from the AS, the device can configure proper CORS settings in advance. It means that the approach would be familiar with the secure local cross-origin access method described in [CORS-AND-RFC1918]).

  • The authenticity of devices can be enhanced when the AS authenticate devices based on attestation keys in TPM on the devices.

• Cons

  • Manufactures have to deploy and maintain their own servers (AS and/or CA).

  • Fetch API needs to be extended.

  • Device domain names are not validated.

  • Another browser API (for example, which allows a web service to pin a certificate in the context of a specific origin) would be needed to support the normal access pattern use case.

5.3.4. APPROACH-4

• Pros

  • Web services can trust devices as far as they can trust private CAs for the devices.

  • Device domain names can be validated if ACME can be extended for local domain names.

  • Existing PKI-based methods for managing the lifecycle of certificates can be used (e.g., CRL, OCSP).

  • If a device can get web service information from the AS which has a private CA role, the device can configure proper CORS settings in advance as with §5.2.2 APPROACH-3: Using Application Layer Access Token.

  • The authenticity of devices can be enhanced when the CA issues certificates for the devices based on attestation keys in TPM on the devices.

• Cons

  • Manufactures have to deploy and maintain their own servers (AS and/or private CA).

  • Fetch API needs to be extended.

  • Another browser API would be needed to support the normal access pattern use case.

6. Conclusion

In this document, we introduced technical approaches to enable local HTTPS communications from browsers to devices that is not publicly accessible. However, these approaches would require browser extensions and other protocol standardization as identified. The motivation came from the industry need of providing HTTPS access to IoT devices, majority of which will not have a global domain name so that the domain name can be verified and a certificate can be issued.

We hope that this document will spur the discussions within the W3C community so that a solution can be developed and standardized.