End-to-End Encrypted Proxy Using Password Protected Certificate

End-to-End Encrypted Proxy Using Password Protected Certificate

I have a thought experiment for the community, curious what everyone's take on it is, specifically what are the major flaws in the idea and how could those be addressed without significantly diverging from the main objective.

Objective

I want to completely restrict access to my web servers to only trusted users without requiring my users to have anything beyond their TOTP device and a web browser. To accomplish this I want to present some sort of endpoint like https://example.com/MyApp01, their traffic is sent to a intermediate server between the user & end application which enables the user to build a in-browser VPN-like end-to-end encryption tunnel between the client & desired application.

Example Use Case

For this example, lets say I work for a large organization in which I have users all around the world working as contractors who don't always have access to a secure internet medium (i.e. China, Iran, Russia etc.) or even access to a personally owned device while conducting their work. These contracts needs secure access to a specific web application in order to fulfill the obligations of their contract such as getting important safety memos or whatnot. Users would be able to access this webpage, establish a secure connection even in the event their TLS connection is monitored.

Traffic

1. [CLIENT] User navigates browser to https://example.com/MyApp01;
2. [SERVER] Application responds to client with a Login page;
3. [CLIENT] User provides username and their MFA token (TOTP) to server;
4. [SERVER] Application locates user account & Validates MFA credential;
            Sends client the users password-protected private key; 
            Responds to client with a login page to decrypt the password-protected private key;
5. [CLIENT] User provides password to the in-browser app loading the private key into memory;
6. [SERVER] Acknowledges user has successfully loaded private key;
            Provides user with a one-time certificate unique to the session.
7. [CLIENT] Now proceeds like a normal web application, except all traffic is encrypted using both TLS & this end-to-end encryption.

Objectives

1. Eliminate (il)legitimate MITM interception of web traffic snooping.
2. No special software required.
3. By placing this functionality on an intermediate device between client & web server; can fully isolate communication to vulnerable servers.
4. End-to-end encryption is transparent to backend web server.
5. No configuration burden placed on end users.

Obvious Observations

1. Most likely significant performance implications;

2. Extremely complicated implementation of the "client side code".

3. Remains vulnerably to on-device attacks;

   3a. If you restrict session keys to client IP; you can significantly raise the level of effort to compromise; this would not work on systems where IPs change mid session (i.e. outbound load balancers).

Subsequent Possibilities

1. Because the user now has a valid private key, there is the possibility this system could be used as a SSO tool, or at least facilitate the functionality by say pulling a OAUTH token for the user.