End-to-End Encrypted Proxy Using Password Protected Certificate

Question

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.

Answer 1

This is an insecure approach. Anybody who knows the TOTP token and username gets the encrypted private key and can then perform an offline brute-force attack on the password without any rate limiting. It's like handing out a password hash as soon as the user enters the correct TOTP token – an application must never do that, because offline attacks are far more efficient than online attacks, and the application no longer has the chance to detect and prevent the brute-forcing. At best, you could invalidate the log-in attempt if the user isn't able to quickly respond with a password (indicating they don't know it), but then an attacker just needs an additional valid TOTP token after they've found the password through brute-force.

In general, the scheme is very complex without providing much extra security compared to standard solutions. I think a lot of this comes from an attempt to combine authentication with transport security. If you separate the two, things might get a lot easier.

In terms of authentication, it seems you want nothing more than standard 2FA with a password and a token. The only special feature I see is that you're trying to check the password client-side instead of transmitting it to the server. I'm not sure this is worth the additional complexity. If the server which renders the log-in form is malicious or compromised, it can sabotage the client-side code to grab the password as it's entered, and there's no realistic way for a user to detect this. So you might as well send the password directly to the server (over HTTPS, of course).

As to transport security, your scheme seems to offer nothing beyond standard TLS which already provides end-to-end encryption.

If you want to have an intermediate server to, e.g., protect the main application, then consider options like a (reverse) proxy or a firewall.

Answer 2

except all traffic is encrypted using both TLS & this end-to-end encryption

Every time your design has this as a goal / feature, you are almost certainly doing something wrong. Considering the case of "(il)legitimate MITM interception of web traffic":

• The MITM gets the TOTP code. This admittedly doesn't matter a lot.
• The MITM can modify the client-side script, enabling it to keylog your private key passphrase.
• The MITM can intercept the "one-time certificate" (whyyyyyyy would you do that?) and replace it with one where they chose the private key. If your client knows to expect a particular issuer of the cert, the MITM can change the client-side script to expect theirs instead.

So, you gain ~no security against an active attacker (which anybody intercepting modern TLS will be; you can't MitM Diffie-Hellman-based key exchanges without it). This is completely transparent to the user, assuming the MitM's certificate is trusted, which is a prerequisite for normal TLS interception anyhow so again your scheme adds no security.

Other problems:

• TOTP is not secure enough to use as a single-factor, and password-based private key encryption is barely secure at all. TOTP is used as a second factor, because the number of victims whose first factor (typically password) is known is small, and you can prevent brute-force attacks on the second factor by locking a password-compromised account after a few bad tries. This doesn't apply to TOTP as a first factor; if you have a million users, I can try one request to each of them with a random code and expect one success per million attempts regardless of user, then crack the private key password offline (and very quickly).
• If you want this level of security, you shouldn't be using browsers at all. The browser security model is a teetering pile of hacks, compromises, and crossed fingers. In the hands of a competent user running a web app carefully reviewed for security flaws, it is usually sufficient, but the attack surface is vast and people love installing untrustworthy extensions, using browsers on untrustworthy devices, and so on. Putting it another way, TLS is one of the best aspects of browser security - though certainly not without its own flaws - and accepting all the others while trying (and failing) to mitigate the flaws in TLS makes no sense.
• Certificates and private keys aren't magic, and aren't sufficient to create a usable secure tunnel. You need a much more complicated hybrid cryptosystem for that. You'd end up basically re-implementing TLS on top of TLS, and almost certainly do a much, much worse job (world-class experts have been spending decades, and six major versions plus many more minor revisions, trying to make TLS secure at the protocol level, never mind the constant stream of implementation vulnerabilities).
• You're largely just moving the problem of "secure an Internet-exposed web server", not actually solving or avoiding it. Your authentication middleware is still a web server, and still needs to be secured, because it can certainly access the back-end server. Furthermore, this does nothing against web app vulns (not that you ever claimed it did, but you didn't explain why you want to isolate the back-end server in the first place).