Now if the problem is that they have an option to configure a proxy, but don't trust your internal cert for the proxy itself, then the answer is to use a publicly signed cert on your internal proxy server. I just did some quick searches and found proxy settings for F5, juniper, cisco, infoblox, and tufin appliances. So the vendors either added the feature for us, or those features didn't work, and maybe we didn't buy it at all. This could also be that for the last 15 years I've been working for very large non-tech companies that just wouldn't budge on giving a random network appliance direct access to the internet.

Now for the last 7 years I've been more on the dev side of devops, but I can't remember seeing any network appliances being sold for 'enterprise' that didn't have an option to enter a proxy for updates, or cloud services, or whatever it needed to phone home for. (And with 'hard' I mean more than some window popping up that says 'Are you sure you want to do this? You'll void all warranty blah blah' - people have already been conditioned to just click away certificate warnings in their browser the same people would just click anything to just go on with their lives.) Maybe an opt-out of certificate pinning that is so 'hard' to reach that it's really only for power users that know what they are doing. Sure, it's the owners responsibility, and with certificate pinning that's not configurable, you are depriving responsible owners of the possibility to decrypt their own traffic, but we at least need to acknowledge that there is a balance to strike here, and it's not obvious what the perfect solution would be. That's a huge pain to implement, most of the ways to do it make everybody's security a bit worse, but it isn't technically impossible.īut technologically we can't change the mathematics of the encryption, Diffie-Hellman works, two parties can agree a secret (which in effect becomes a symmetric key) without either of them uttering the secret.Ī problem is that the easier you make it to sneak in other trusted root CAs, the more you open attack surfaces which malicious parties can exploit.Īs a device manufacturer that uses certificate pinning, do you really want to trust whatever cheap crap router people have at home to provide a trusted root CA? Let's say that one gets hacked (which happens too often.), you are now also wide open. You also could legislate from the far end, for public services, you could say if I own a device using my credentials to do stuff, I get to have the agreed key material so that I can decrypt messages after the fact. After all the EU mandated people provide a sane charge port on phones and it more or less worked, even if you don't live in the EU your phone likely no longer has some arbitrary custom charge port on it, and you can buy replacement chargers or keep the one from a previous phone, reducing waste. Governments could legislate of course, there could be a rule that means you can't sell Nest because it doesn't have some 'hack' feature. This is useful for determining what domains apps need to access and creating whitelists.īut this is a decision you in effect made, those devices needn't even use TLS, they could use Jim Bob's secret MITM-defeating crypto thing and you can't 'hack' that either, you bought devices that are resistant to being reverse engineered. It can also export a list of all domains that the user allows to be resolved. It falls short of instecting the contents of the requests, but it does allow the user to export lists of all DNS/HTTP requests. In that case, installing NetGuard available from F-Droid will allow the user to list and optionally block DNS/HTTP requests. 'Tech' companies do not pay the costs of transferring the data/information, users foot the bill.Ī cautious user could decide that if the 'tech' company will not share with her the deatils of the user's data/information being sent to the mothership, then she will just block the requests.

After all, it is the user's network, it is the user's computer and it is the user's data/information, not the 'tech' company's. Assuming the people running 'tech' companies wants users to trust them, the user's data/information being transferred to the 'tech' company should be available to the user. The part about being able to see 'what they're saying' is interesting. I have not run into any problems with HSTS. Instead of Burp, I use Haproxy running in Termux. 'All I want is to be able to see who my device is using my network to call, and what they're saying.'

How to decrypt wireshark captures