Encryption options when one-way secure channel is available

Question

I would like to ask what encryption options are available for the following real scenario:

• There is an unsecure, full-duplex communication channel between a server and client
• There is also a secure one-way communication channel from the server to the client

From this it is sought to have secure full-duplex communication. The existence/timing of messages is not considered a liability in/of itself.

The motivating scenario is:

• A software application with a user-interface including an embedded web-browser
• The native application code can inject javascript into the web-browser for execution (this is the secure one-way communication channel)
• The native application code interacts with the web application using http WebSockets (this is the unsecure, full-duplex communication channel). The native application contains the server and the web application contains the client.
• There is no other means of communication between the native application code and the web application.
• In this scenario, Websocket over https is not considered an option due to the certificate management complexity.

Edit: additional details:

• The client webapp only receives the port number when the server begins listening on that port (the port number being conveyed via javascript injection which initiates the WebSockets connection). This (I believe) mitigates server authentication needs. Client authentication is still wanted.
• The system must work offline
• The HTML/javascript of the web application is fully trusted.

Answer 1

First of all, this scheme is risky. You have to make sure that your embedded web browser (webview) is connecting to your server, not a malicious one running on the same port; this is possible to guarantee but error-prone in practice. Additionally, trying to implement secure communication by hard is very error-prone; even using primitives from a library, rolling your own cryptography is a bad idea. I recommend one of the following architectures instead:

1. Have the native app (and the webview, if you must have a webview) connect to a WSS server that is located at a known address and acts as a relay.
2. Have the native app set up a JS "bridge" such that the webview can invoke the necessary functions in the native code, giving bi-directional communication.
3. Have the native app monitor the webview's URL, and use navigation with URL query parameters (or possibly just set the fragment / use history.pushState) to transmit data back to the native code.

---

With that said, this is a a relatively easy situation for key exchange. Since you already have a secure channel, you can just generate a symmetric encryption key (using a cryptographically secure [pseudo-]random number generator) in the native code, and pass that into the webview. Using an authenticated encryption scheme, you can then securely send and recieve messages using that key, with the assurance that the other party must have the key. This doesn't provide all the protections of TLS - in particular, it's missing the replay protection that comes with TLS, so if replay attacks are a concern you'll need a way to deal with them (usually a counter or other nonce within the encrypted message) - but it's probably good enough if you really must do things this way.

It helps if the source of the HTML in the webview is fully trusted (e.g. is put there by app native code, or pointed at an HTML file in the app's private directories, or at least is coming over HTTPS from a domain you control) rather than making a request to the app's webserver. This way, you can reasonably trust that the key you inject into the webapp is only visible to trusted HTML/script.