I am working on a device that should sit between the end-user and the server, and that will do deep packet inspection. It is basically a parental control node. This device will be sold to the user, so they will have full knowledge of what it is and what it does. Getting this to work over HTTP is fairly straightforward, but for this to be of any real use, it clearly needs to work over HTTPS as well. I have a few questions on this scenario, and I would appreciate your insights:
Do you think this is a legitimate use case for a man-in-the-middle attack? I feel like it is, and that it's technically no longer an attack..
What do you think is the least-friction way of doing this? This should be as easy as possible for the end users to configure. I am thinking of configuring the box as a transparent proxy, and getting the user to accept a root CA in order to forward the traffic. I played around with mitmproxy, which somewhat does this. But the process is somewhat unpredictable. For instance, Firefox can directly accept root certificates in one-click, while Safari on OS X requires you to add the cert to your keychain by putting in your root password. Any thoughts here would be appreciated. Maybe installing through browser add-ons is easier?
How can this device recognize that the end-user has the proper root CA installed? Is there a test to see if the user is accepting our certificate, so that if they aren't we send them to a "installation directions" page, for instance?
I was told that cert pinning would invalidate this process, but I can't find too much info on that. Do you think this is a concern?
There seems to be a proposal in HTTP/2.0 regarding Explicit Trusted Proxies. This sounds like it would fit exactly my use case. However, this proposal also got some very bad rep. What do you think about this proposal? Do you think it will ultimately be beneficial for the end-user?