> nobody should ever get used to the idea that their network is MITMing their traffic
and:
> surveillance technologies like this will be abused by people with power over others
Then simply do not add a CA or self-signed cert to your cert store. IOW: the default is secure against SSL MITM. Nothing to "get used to" or "abused".
> What happens when libraries and software starts dropping support for old, insecure protocols, and the new protocols are designed to treat MITM as an attack?
Much simpler than you think. In an Enterprise, they block what they cannot inspect. Clients do not own+run the networks, the enterprise does.
> What happens when they're spending huge amounts of money maintaining forks and patches?
This runs counter to your earlier argument: "You can block spam and outbound attacks without MITMing traffic."
How do you control a myriad of versions of client software on a myriad of versions of devices across a myriad number of applications? There are bound to be some software the Enterprise cannot control (e.g. proprietary, or simply does not have the resources to fix+recompile).
Once upon a time, there were public CAs who would sell you a sub-CA certificate for use on a hardware MITM box, so that you could "transparently" MITM systems on a network without adding a CA. That is now considered unacceptable, and grounds for terminating a CA. What "security" practices in use today will we be saying "once upon a time" about years from now?
Can an industry not mature?
Previous behavior is not an indicator of the future - and anyone worried about it can contribute to scrutinizing CA's and their guidelines today.
Not sure pre-judging current actors based on past actions during a relative nascent industry gets us anywhere - especially since you still haven't provided an alternative solution for enterprises to prevent data breaches or data exfiltration WITHOUT inspection happening somewhere else other than the egress chokepoint.
Among many other reasons, because such entities repeatedly try to weaken Internet security standards and software to accommodate their expectations. That's an attack, and deserves an appropriate response.
Also, because today, everyone doesn't always have enough choices of potential employers that they can avoid such policies.
Also, because nobody should ever get used to the idea that their network is MITMing their traffic, not least of which because that normalizes such technologies on other networks and in other contexts.
Also, surveillance technologies like this will be abused by people with power over others; there's a long history of such abuse.
And those are just the reasons off the top of my head.
> Go ahead, you're increasingly unlikely to win that battle.
What happens when libraries and software starts dropping support for old, insecure protocols, and the new protocols are designed to treat MITM as an attack? What happens when, even before that, companies that MITM have to replace cheap MITM infrastructure with incredibly expensive MITM infrastructure? What happens when software and services start treating the resulting decreasing percentage of companies that try to MITM the way they treat companies still running IE6, and tell them "you'll have to upgrade your network"? What happens when people trying to MITM find they can't run modern software stacks, and their auditors complain that they're not upgrading? What happens when they're spending huge amounts of money maintaining forks and patches? What happens when the engineers who would have to maintain those patches don't want to work on a hostile network, and the ones that remain are more expensive? There are many things people can do to make life difficult for anyone trying to MITM.