2 ms·
> Such networks are security threats and should be repeatedly broken until they give up. Why the hostility towards entities that have determined their best cou
by droitbutch 6y ago
> Such networks are security threats and should be repeatedly broken until they give up.
Why the hostility towards entities that have determined their best course of action to protect THEIR networks is by focusing on the network egress pipe? Simple and efficient to focus on one chokepoint vs patching a myriad of devices + client software + client versions + OS versions + future versions etc.
> It will become increasingly expensive to even try.
Go ahead, but you're increasingly unlikely to win that battle. There's bound to be some software or version that the enterprise cannot control (e.g. prevent data exfiltration) at which point, enterprises will have no solution but turn to SSL MITM again.
Remember, it's the enterprises' network and data - not yours.
- JoshTriplett 6y ago> Why the hostility towards entities 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.
- droitbutch 6y agoYou seem to be conflating enterprise and home/personal networks. They are not the same. > 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).
- JoshTriplett 6y ago> 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". 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?
- droitbutch 6y ago> 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.