TLS JavaScript API

[CendioOssman]

Introduction

Some more advanced web applications want to interact with existing, non-HTTP services. These other services use TLS for security, and hence, the web application needs to be able to communicate using this protocol.

The browser already has a well polished TLS implementation. It would be in everyone's best interest if the web application can leverage this and not have to resort to having a more complex setup with its own TLS protocol implementation.

Use Cases (Recommended)

noVNC is a popular VNC client for the web. Modern VNC servers implement TLS and often also require it. noVNC cannot currently communicate with these and forces uses to disable TLS in at least one hop to make things work.

Goals (Optional)

A JavaScript API where a web page can proxy data between its communication channel of choice and a browser provided TLS stack.

Which policies should be decided by the browser, and which by the application, is yet to be decided. There is a possible big advantage of letting the browser handle things so the user has a consistent security exposure.

Some mechanism for certificate exceptions should be available, though, as it is common with self-signed certificates. The same policy the browser implements for HTTPS is likely fully sufficient, though.

Non-goals (Optional)

None at this point.

Proposed Solution

Probably best to model a TLS object after something similar, e.g. WebSockets. One addition that is needed is a mechanism for how to connect it with the "real" transport.

A specific suggested design has not been done yet.

There might also be APIs from the non-browser world that could be used as inspiration.

Alternate Approaches (Optional)

1. Use a purely JavaScript API. E.g. https://github.com/digitalbazaar/forge. Downsides are:
   a. Worse performance
   b. A second TLS implementation, likely less well tested, increasing attack surface
   c. No ability to coordinate policy with the browser

2. A more protocol aware proxy that bridges the web application and the non-HTTP service. This means a much more complex bridge that needs to be implemented and maintained. Besides the extra work, more code again means more attack surface and more risk for bugs.

Privacy & Security Considerations

TLS is big and complex, so security and privacy risks definitely exist. The hope is that we can leverage the existing TLS implementation so that the risks are no more than what already exist.

An important detail for this is how much control will be given to the web application. More control means more risk for both privacy and security. We'll need to explore what is needed and what can be kept with the browser.

Let’s Discuss (Optional)

The API is probably the biggest area of discussion, given that browsers use various underlying TLS implementations.