Legitimate use case of man-in-the-middle attack for DPI?

Question

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:

1. 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..

2. 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?

3. 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?

4. 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?

5. 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?

Thanks!

Answer 1

This is possible technically to achieve but there are some problems with it. In response to your questions

1. Some would agree with you that this is a legitimate use of MITM. There are already popular products in the corporate world that implement this approache (e.g. BlueCoat)

2. The least friction way of doing this would be to get signing cert signed by a known Certificate Authority, and then create legitimate certs as needed. Unfortunately unless you're the government that's not a likely option. The standard way to approach this is as you say, get users to install your certificate authority into each device in use. I don't think browser add-ons would work

3. I'm not aware of a way of doing this without installing additional software, which would in effect be the same level of effort as installing your cert, so not a lot of point really.

4. Yep Certificate pinning will cause problems with this and is becoming more common as time goes by. The way this works is that the browser knows of a specific certificate or set of certificates that it trusts for a given hostname, and it won't base that trust on certificates being issued by a known CA. I'm not aware of a way past that problem.

5. I've done a little reading on that proposal and from what I understand of it I'm not a fan.

Another problem for you to think about with the kind of product that you're looking at is, how do you handle invalid certificates when your device encounters them? Say for the sake of argument your proxy makes a connection to a site and it has an invalid certificate. Do you

a) issue a certificate to the user that's valid (e.g. signed by your device CA). At this point what if that site is a phishing site and you've just stopped the user from identifying that the certificate was invalid which could have alerted them to the problem?

b) issue a deliberately invalid certificate from your CA, so that they can see the problem. Most users (assuming that they're savvy enough to look at certs) will then just assume it's a problem with your device.

c) pass the connection straight through so that the user can make a correct determination that they could be connecting to a malicious site? At this point that becomes a known way to bypass your device and you also lose the ability to protect the user from malicious content on that site.

or

d) Block access to any sites with certificate errors. This is probably the best way to solve the problem but still leaves you with a customer perception issue "we installed this thing and it broke access to our site"