A solution to prevent man-in-the-middle attacks

The balancing act between risk and trust with man-in-the-middle visibility is two fold:

1. Corporate and Government networks need insight in to the data traversing their networks to protect them from advanced attacks, malicious insider threats, and inappropriate activities.
   
2. End users want a certain level of privacy for trusted services, like banking, medical communications, and other sensitive traffic. There are some that will respond to this with “do not do personal things at work!” However, in our hyper-connected world where the lines between work and home are often heavily blurred, that draconic view is no longer valid. 

The solution today is to find an SSL man-in-the-middle solution that is policy based, something that will not decrypt sensitive traffic while decrypting everything else.  However, the problem with this is the end user has no visibility in to what that policy is and if their sensitive traffic was added to the exception list.  This is further complicated by the fact that once the root CA has been loaded in their browser there is no visual indication that this traffic will be intercepted.

To solve this problem and give end users the protections they want, I see a time coming when you will no longer need to use RSA or Diffie–Hellman to exchange keys beyond the initial account creation process with the service provider (if you went in to the brick-n-mortar facility then you would not even need that). Imagine if during the account creation process you could create a symmetric key with the provider along with some extra algorithm information for OTP randomness. You could then type that same key and OTP randomness in to a browser plugin for that site and never need to use standard SSL key exchanges again.  This would nullify all SSL man-in-the-middle attacks.

Given that it only takes one person with access to sensitive network traffic to cause problems, end users are hungry for solution to protect their privacy.