Adapted Browser behaviour for local connections

Changing browser behaviours

In order to establish truly secure and usable local connections, some change to the current standard browser implementations is ineveitable.

This change either needs to be made to ALL current browsers (which probably means routing the changes through teh CA Browser forum), or it will require the creation of a new specialised browser type.

In either case it make seense to minimise the changes necesssary.

This section will clearly define the proposed browser behaviour for each conditions

Approach

Current browser security is based on certificates. If we wish to minimise browser implementation changes (see above), then the proposed solutions should also clearly outlined how they can work with existing certificate primatives.

The overarching approach, will be to separate out the issues of

  1. Defining the browser behaviour when presented with a particular certificate type, and
  2. Defining the mechanims by which a browser is provisioned with a certificate

This separation of concerns, will requires us to clear define the certificate types

We have already established that, some certificates are already in use for deployed IOT devices. Our proposed solution must recognise this fact.

Additionally, there is the opportunity to define, new certificate structures which manifests the pertinent local/IOT setup within the certificate expression. This in turn allows for cleaner separation of function, simpler deterministic browser behaviour changes, and a transparent declaration of intent within the expressed certificate.

Non certificate based security

Additionally, we will define the method by which browser behaviours can be modified to make user of non typical HTTPS certificates For example security emanating from a embedded sim card, or security artefacts accessible from lower parts of the networking stack.

Current browser algorithm

TODO

Maybe this goes in background section

Decision flow needs reviewing

Current warning issued

TODO

We need to add examples of the current warnings. Maybe this goes in background csctions

List out the current warnings for typical browsers

caution

Browser dependent

Recommended behaviours for existing certificate types

The recommended browser behaviour should clearly indicate the desired behaviour when presented with existing certificate types

With reference to the certificate types defined in [4-certificate-background]

Certificate TypeRecommended behaviour
0. No certificate (null)User should be presented with warnings, similar to current browser warnings, but extra information telling the user that they are browsing a local resource
1. Non device unique - self-signed certificate (NU-S/S)Strong warning to the user that this certificate can be easily stolen, and provides no real assurance of the provenance of the devices, nor security.
2. Non device unique - untrusted root-signed certificate (NU-U/S)Strong warning to the user that this certificate can be easily stolen, and provides weak assurance of the provenance of the devices, nor security.
3. Device unique - self-signed certificate (U-S/S)This connection is secure, but there is not additional information to advise teh user of the provence or history of the device.
4. Device unique - untrusted root-signed certificate (U-U/S)Types 4 & 5 may be the same thing. All the solutions that follow are different ways of provisioning the device with different flavours of certificate.
5. Device unique - locally-signed certificate (U-L/S)
6. Device unique - CA root signed certificate (U-CA/S)Currently this behaviour will work without warnings. Potentially the browser could give additional advisory that the user is currently browsing a local resource.
TODO

Need to look at the difference between 4&5

Adapted certificate types for IOT and Local usage

TODO

This needs some more work to clean up

Some options to consider

Local usage marker

Key Usage and Extended Key Usage could be used with a predefined field to indicate that this certificate has specifically been issued for intended local usage

IOT usage marker

Key Usage and Extended Key Usage could be used with a predefined field to indicate that this certificate has specifically been issued for IOT usage. This example differs from local usage marker in that

  • IOT device might potentially addressable on the public internet space
  • A certificate issued to software, should be different to a certificate issued to an embedded physical device.

Standard certificate

A traditional certificate binds a common name to a public key, using an external trusted authority.

As such it provides assurance to a user that the name they are using to address the endpoint, is XXXXX

It is use primary, is to provide end to end assurances over what is essentially an unreliable name resolution method

User provisioning

An additional feature we may want form an extended browser accessible certificate, it to have evidence that the "local user" has intentionally provisioned the device within the internal network. This protects against devices self advertising themselves on a network that they have access to.

Device attestation

Another additional feature we may want form an extended browser accessible certificate, it to have evidence of the provenance of the device. some form of device attestation, proving the device is from a recognised device manufacturer.

Non certificate based integration

TODO

In this section we should define the method of integration and the proposed decision tree for browser behaviour if using a non certificate based security anchor

TODO

Alternatively we could define how the low order, security framework maps onto and issues an browser accessible HTTPS certificate

Impacting browser changes

Lobbied browser changes

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

  • Time: it will 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 will be successful.

Request Browsers to use softer warnings

A friendlier user experience would be to request browser vendors to distinguish between certificates served on 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 can not be verified."

With 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 webservices more intuitive for common users.

After the initial warning, the browser will connect to the end-point device over an encrypted TLS session. 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.

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 trust are likely to be considered and accepted. It would require strict rules under which a local certificate could be signed by a Root CA.

Similar to 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.
Edit this page