This repository contains the RDE client proxy server. It is written in python and uses the Flask framework with Flask-Sock.
The easiest way to run the proxy server is to use the docker image. The docker container uses gunicorn as a WSGI server and exposes port 5000. The gunicorn server is configured to use 1 workers with 100 threads each (100 concurrent connections).
Note that multiple workers are not supported at the moment, as the RDE client uses a simple variable to store the current open connections.
The sole purpose of this proxy server is to enable communication between the RDE JS client, running in the browser, and the RDE app running on a phone. The proxy server is a simple HTTP server that can open up WebSocket connections for a specific token. The server will function as an echo server for all WebSocket connections: it simply forwards all messages it receives on one connection to all other connections that are open for the same token.
This server is not meant to be used in production currently. It is a proof-of-concept implementation that is meant to demonstrate the feasibility of the RDE prototype. In production, the endpoint to create a new token for opening WebSocket connections should be authenticated. Also, inactive sockets should be closed after a certain amount of time, and the server should make sure the correct protocol is used over the sockets.
The sole purpose of this server is to enable communication between the RDE JS client and the RDE app. The server does not store data or process any data in an unencrypted form. However, under the current decryption handshake protocol, an active MITM attack on the proxy server could allow an attacker to get access to the retrieved key. This is because there is no further confirmation that the browser and app are using the same shared secret. This is a known issue and should be addressed in the future, but is not a priority at the moment. It can easily be resolved by adding some confirmation token to the handshake protocol. This token can be generated by the app and manually be entered by the user in the browser, and used to construct the shared secret. This way, even if an active MITM attack is performed, the attacker will not get access to the decryption parameters (which are not secret) and the recovered key (which is secret).