zlacker

Isn't MITM required in enterprise environments where they want to filter content? Unless you want to run it client-side which isn't usually an option.

>>Viper0+(OP)
> Isn't MITM required in enterprise environments where they want to filter content?

Then don't filter content.

>>Viper0+(OP)
There are ways to filter content without breaking user privacy. For example, you could restrict access to the Internet altogether, and suggest that your users only get what they need from your internal corporate network. See how incredibly productive that makes your staff?

What these "enterprise environments" want is to leech off the Internet's knowledge while keeping a firm chokehold on the privacy of their own employees Sadly, it looks like Google is caving in to their pressure.

>>parenn+V
> Sadly, it looks like Google is finally caving in to their pressure. Maybe someone like Mozilla won't.

All browser vendors provide the necessary bits for properly implemented HTTPS MITM, and have done so for ages (which are fairly simple, basically "allow local trusted certificate roots and ignore key pinning for them").

>>Viper0+(OP)
Basic filtering can be done via passively inspecting SNI headers and terminating connections to verboten hosts. However, that's not enough for some orgs, and some software works around it: https://www.bamsoftware.com/papers/fronting/

>>emmab+z
At my workplace we need to use middleboxes like this for 2 reasons

-our commitment to our customers and regulatory compliance requires we know where customer data is at all times. It would be lovely if all employees could be trusted with data at all times, but the reality is some employees will steal information, as google found out with Levandowski. That's google's own information though; they don't have a regulatory requirement to report the breach, whereas the data I protect requires full disclosure legally.

-malware is increasingly using https to communicate with C&C. Many malware families now install a trusted root cert so they can exfiltrate data on less monitored 443 rather than 80. When (not if) devices get compromised we need to know what the attacker got.

I would love to not need to do this because it's a privacy mess and breaks applications all the time, but there simply are not better tools to serve as the last line of defence against data loss.

iOS has mostly solved this problem through a combination of not running unsigned code and APIs where MDM can draw a corporate data barrier inside the phone, but while desktop OSs remain there will need to be some form of this.

>>emmab+z
Great, as long as the world is black and white and completely susceptible to binarization.

>>parenn+V
> What these "enterprise environments" want is to leech off the Internet's knowledge while keeping a firm chokehold on the privacy of their own employees

Because one size really does fit all, and all environments have the same needs?

>>discre+s1
Even simple tls handshake filtering is broken with BlueCoat's implementation.