Change Browser Behaviour

In order to achieve the objective of securely negotiating sessions between the local browser client and the local web server (IoT endpoint device), we need to look at the interactions with the browser.

In the first instance we shall consider how to change the browser behaviour so that it issues appropriate warnings.

This method should clearly define exactly how the browser should behave when it sees different certificate types

Current Browser Decision Method

flowchart TD A[Resolve name to address] -->B[Connect to server, Retrieve cert]; B --> E[Validate certificate]; E--> F{Is it valid ?}; F-->|No| G[Issue cert warning]; F -->|Yes| H[Continue];

Certification validation usually includes checking the OCSP status, which ideally has been "stapled" to the certificate, but could instead involve a second network transaction.

Add locally relevant certificates to decision tree

flowchart TD A[Resolve name to address] -->B[Is address Local?]; B --> |Yes| L[Do local validation]; B --> |No| E[Validate certificate]; E--> F{Is it valid ?}; F-->|No| G[Issue cert warning]; F -->|Yes| H[Continue];

A local address would consist (at the least) as being one which is an IPv6 Unique Local Address (ULA, fd::/8), for which there is a directly connected interface, an IPv6 Link-Local address (LL, fe80::/10), and IPv4 Link-Local address (169.254.0.0/16), or an RFC1918 address for which there is a directly connected interface.

A directly connected address is one for which there is an interface on the local machines within that subnet. This would be the /64 ULA for which the machine is connected, or the RFC1918 address (e.g., 192.168.1.0/24) for which the machine is connected.

Additional addresses which might be considred local

There are some potential extensions to this list which could be considered, but which maybe should not be default.

• IPv6 ULA addresses which are not directly connected. This is unlikely to appear in the majority of homes, but could be present in some homes runs by IT professsionals.
• IPv4 RFC1918 subnets which are not directly connected, which could be due to multiple layers of NAT44, or which are used by an ISP. These subnets are less likely to be local.
• IPv6 GUA addresses/subnets which are directly connected.

Rebinding attacks and local resolution

There is an additional concern which is that the name address mapping must occur via some locally trusted process. If it is permitted for the mapping to occur via public DNS, then a Rebinding attack can occur. One explaination of this kind of attack is at: https://danielmiessler.com/blog/dns-rebinding-explained/ The mapping must therefore come from mDNS/DNS-SD (aka "Bonjour"), or must be within some trusted local DNS zone.

Local Validation

The above step "Do local validation" is not well defined. The most trivial thing is to do no validation, but just accept the certificate as is.

There are some additional steps which could be added:

1. automatically do Trust on First Use (TOFU), and subsequently always validate that the same certificate is connected to the same IP address.
2. validate that the IP address or certificate is not currently trusted by as attached by a different device.
3. some kind of third party validation through a manufacturer trust tree.
4. examination of the subjectAltName that includes an IP address name, or an OUI/IEEE ethernet address validation, along with a check that the connection is to that actual MAC address.

Recommended Behaviours

The recommended browser behaviour should be adapted to fit the category of the certificate.

The provisional high-level recommendations are:

Certificate Type	ShortHand	Recommendation
No certificate	NULL	DO NOT USE Recommend strong warnings if attempted
Non device unique - self-signed certificate	(NU-S/S)	DO NOT USE Recommend strong warnings if attempted
Non device unique - untrusted root-signed certificate	(NU-U/S)	DO NOT USE Recommend strong warnings if attempted
Device unique - self-signed certificate	(U-S/S)	DO NOT USE Recommend strong warnings if attempted
Device unique - untrusted root-signed certificate	(U-U/S)	POTENTIAL USE Method for provisioning certificate need defining and appropriate UI designed
Device unique - locally-signed certificate	(U-L/S)	POTENTIAL USE Method for provisioning certificate need defining and appropriate UI designed
Device unique - CA root signed certificate	(U-CA/S)	USABLE NOW Warnings could be changed to help differentiate

Extended Certificate Based

Underneath the coarse certificate characterisation above, it is possible to manifest further information within the issue certificate that would help the browser make its decision on what to feedback to the user, and whether to proceed with the connection.

• Key usage and extended key usage have already been mentioned. If, for example, we wish to clearly denote that a certificate has been issued to an IoT device (not a server), this information could be manifest in these fields to help with the decision process.

• Complex or multiple certificates the use of certificates (or similar technologies e.g. verified credentials) could be extended to represent multiple factors which help with the security decision. For example before a user connects to a local device they might need assurances that:

  • This device has been securely onboarded to the network and the user's account (e.g. an ownership voucher).
  • This device is from a recognised manufacturer (e.g. device attestation).

Non Certificate Based

This section is left as a place holder to discuss the browser and user notification changes that would be needed if we were to use a non-certificate backed method of negotiating the TLS session.

Non TLS Based

This section is left as a place holder to discuss the browser and user notification changes that would be needed if we were to use a non-TLS based security connection.

Potential New Browser Decision Method

A modified decision tree could be defined for browsers that fully accommodates the proposed changes for local connections.

More experimental work is required before this can be fully fleshed out. But key considerations for this decision tree should be:

1. What is the certificate issued for? Is it for use on a globally addressable web server or for locally addressable IoT device? The key usage field in the standard X509 certificates may be a good implementation of this feature.
2. Where is the certificate being served from? Both the device and client know when TLS is being negotiated, whether the device is on a private-use local subnet or on the publicly addressable Internet
3. Is the device from a recognised/trusted supplier? This may be a security relevant item that needs surfacing to the browser level.
4. Is the device known? Over and above being provisioned on the physical network, does the device have any deeper notion of Binding to a user (like ownership or commissioning)? Is this security relevant information that needs surfacing within the web session?
5. What name was used? What name was used to address the device? A standard TLS X509 negotiation checks that the name used when addressing the target device is the same as the name in the certificate. If we are to use a different name resolution mechanism, we may need appropriate analogous checks.
6. Has the certificate been revoked ? In the case that the certificate has not been issued by one of the typical roots, does the certificate need checking for alternative revocation methods?

Name Resolution Methods

Some of the methods to be discussed later will introduce name resolution methods.

It stands to reason that this name resolution method has to be implemented within the browser itself.

This would be an implementation change to the networking layer, and would need to be accompanied by appropriate user interface changes.

Lobbied Browser Changes

Lobbying for browser changes would address some of the drawbacks above; the user can benefit from a differentiated UI, better local device addressing and resilient local behaviours. These benefits are experienced across existing and future browsers. The drawbacks are however:

• Time: it would take time to lobby the CA/Browser Forum and longer for any changes to propagate into available browser implementations.
• Indeterminacy: there is no guarantee any such lobbing would be successful.

Request Browsers To Use Softer Warnings

A friendlier user experience could be achieved by requesting browser vendors to distinguish between certificates served on the local network versus self-signed, invalid or revoked certificates on the Internet.

Currently the message is:

"Attackers might be trying to steal your information (for example, passwords, messages, or credit cards)"

Instead browsers could display a message on how the validity can not be checked for local networks, for instance:

"This service is on the local network and the certificate cannot be verified."

If the browser could offer a single click option to abort or continue, it would give users the opportunity to identify the device they are connecting to. This does not introduce trust in private networks, but does make device management web services more intuitive for common users.

After the initial warning, the browser will connect to the end-point device over an encrypted TLS session.

Other Browser UI Feedback

Over and above the transitory warning messages, other UI feedback exists to demonstrate security. When browsing HTTPS sites on the public Internet, most browsers adopt the convention of displaying a "padlock" next to the address. For this scenario where the user is browsing a local resource and where the certificate security semantics are subtly different, an alternative but consistent UI metaphor should be considered.

Possible options include:

• Device icon: indicating to the user they are browsing a local device resource.
• Address differentiation: emphasise the differentiation of the address format, using syntax or prepends.
• Chrome changes: make a wholesale change to the browser chrome (UI outside the HTML render) to indicate we are browsing a local resource.

Method of implementing browser changes

In order to see the desired changes come to light some change almost definitely is required in the implementation of browsers.

There are a few broad strategies for enacting this change. These options are not mutually exclusive:

1. Create a demonstrator browser: this is not necessarily intended for widespread use, but demonstrates a proof of concept.
2. Create a general purpose IoT enabled browser: this could build on (1) and creates a consumer-centric browser which is intended for widespread usage.
3. Create browser extensions: use the existing extension methods available in common browsers to add the required functionality that allows for secure local browsing.
4. Upstream browser changes in open-source code bases: create the changes on the original code bases in an attempt to upstream the changes.
5. Lobby CA/Browser Forum for changes: lobby the Forum to enact the required changes in the Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates.

The last option is the most complex but has the broadest reach impact.

Propose CA/Browser Forum Amendment

Currently CAs are not allowed to sign certificates for internal names

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

7.1.4.2.1. Subject Alternative Name Extension

Certificate Field: extensions:subjectAltName\ Required/Optional: Required\ Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully‐Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right‐most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines.

CA/Browser Forum accepts or rejects change proposals with a ballot.

It would be possible to propose a modification on 7.1.4.2.1 to allow signing of internal names in specific cases. Because CA/Browser Forum guards the trust in the certificate store, changes are not accepted lightly. Only changes that will not jeopardise that trust are likely to be considered and accepted. Such a change would require strict rules under which a local certificate could be signed by a Root CA.

As in the "softer warnings scenario", where the user is browsing a local resource and the certificate security semantics are subtly different, an alternative but consistent UI metaphor should be considered. Possible options might be:

• Device icon: indicating to the user they are browsing a local device resource.
• Different colour: change the colour of either/both the icon and the address.
• Address differentiation: emphasise the differentiation of the address format using syntax, prepends or colour.
• Chrome changes: make a wholesale change to the browser chrome (UI outside the HTML render) to indicate we are browsing a local resource.