And that's the thing. There is nothing stopping those companies from analyzing the data once it reached a managed computer. It is just that they want the capacity to do that on computers they don't manage.
You cannot get out of the network unless the traffic is proxied. There are a few exceptions for identify based reverse proxies that companies like Google talk about. But most places aren't there yet for sensitive applications outside of collaboration.
There's also the matter of trust. Some business partners are explicitly trusted, either by a private CA signed certificate or by a specific third party key that is independently validated.
Public networks are completely different. I am not talking about an ISP here.
That said, your use-case of intercepting secure connections in your private network is a solved one: set up a private CA.
Wanting to weaken the security of TLS for everyone else for what amounts to your own convenience is very selfish.
Unfortunately (?) some companies are actively working against IT administrators (and in my case, parents) ability to inspect TLS traffic on their networks - Google being a big one with the recent release of Android Nougat requiring apps to opt-in to allowing user/admin installed CA's to be honored. User privacy is important, but if you're using a company-issued phone or allow their MDM to deploy a CA to the trust store on your own phone you should know what you are signing up for. Google Chrome pins the certificates for google-owned sites as well, so even if your private CA is installed in the system trust store it will flat out refuse to load google.com, etc.
Whitelist would be safer, but it’s not worth the headache - we use blacklisting to try and prevent accidents for brief periods when we can’t supervise her access instead of falsely thinking it eliminates the need for supervision entirely.
Regardless, still need TLS inspection either way - even pbskids.org is served over HTTPS these days.
Sounds like it could be a worthy venture. Make this software running on dd-wrt or whatever, then sell people wifi-routers with this preloaded so that they can just plug it to their existing routers with ethernet, and voila they have a kid-friendly separate wifi.
I could, but it's a lot more work than just installing Sophos XG on a used server and enabling filtering for certain users. I could also show my wife how to use the admin interface and add additional sites to the whitelist, but there's still the issue of CDN's and such that make life difficult.
> Sounds like it could be a worthy venture. Make this software running on dd-wrt or whatever, then sell people wifi-routers with this preloaded so that they can just plug it to their existing routers with ethernet, and voila they have a kid-friendly separate wifi.
Some companies already sell content filtering devices that sit somewhere on your home network, I'm not a fan of them because they usually require you install some client on your devices or use a captive portal for authentication. Some also have a monthly/annual subscription or those that don't I worry how they even afford to keep the list up to date once they get out of growth stage (or I'm out $$$ for the hardware if they fail to exit it at all).
I realize my setup at home isn't for your average user, but one huge advantage I have that nets it a high Wife/Spouse Acceptance Factor is authentication to my firewall is done through RADIUS accounting packets and I already have AD deployed at home. The moment you login to my network the wireless access point or switch (if wired connection) tells the firewall what user is assigned to a specific IP address, so my wife just signs in with her AD credentials on her iPhone/surface pro/etc. and the firewall already knows to let all her traffic through, if my daughter signs in on her computer/iPhone (she has my old 6+ to play games on) traffic is immediately filtered.
Also, do you know of any way to filter YouTube (other than outright blocking it)? E.g. only allowing content from a whitelist of channels? YouTube Kids isn't really effective, unfortunately.
A root CA that has been installed by the computer administrator is assumed to be more trustworthy than the one installed by your OS.
I've worked in these places and I won't work for them. It places trust in my employer and other employees (most of which I will never meet) that I'm not willing to give. Sure you can tell me that certain sites aren't intercepted, and I can tell that from the origin of a certificate, but many employees can't and don't understand any of this.
If your data is really so secure setup an airgap. There are other ways to securing a corporate network that don't involve a 'just in case' dragnet.
Ditto, but my solution is to just not login into any important/private/nonpublic stuff on employer networks. There's plenty of other non-proxy stuff an employer can install that I also don't trust, and won't necessarily detect, that this seems like a good general policy - irrespective of my employer/coworkers. And if I'm going to be taking that "assume I have no privacy" security stance anyways... them being up front about one of the technologies they're using to secure stuff is, if anything, a good sign.
I've got a non-MITMed cellular connection on my own hardware in my pocket if I'm really hard up for a private connection. I do draw a line at the point where anyone wants to install anything on my own devices. I've temporarily allowed it exactly once - with the device not leaving my sight, and with it being reformatted by myself both before joining it to the work network, and then again before joining it to my home network (although given the potential for firmware malware / IME type stuff, perhaps that's still not cautious enough.)
> If your data is really so secure setup an airgap.
Been there. And I'm paranoid enough to be half tempted to set one up at home. They're a PITA for some workflows though - e.g. needing to play a game of telephone for SDK updates. And then you still can't browse Facebook or whatever with your corporate network. Intercepting traffic instead of completely blocking it is a convenience/security tradeoff.
> but many employees can't and don't understand any of this.
This is admittedly a problem. And they still won't even when the IT department says "we've basically installed our own malware onto 'your' computers / our network, maybe don't log into your bank account from work, we're already going to be feeling terrible and losing sleep if/when our security appliance gets pwned."
So maybe it'd be a good idea ethically and exposure-wise to block facebook/google services/banks if you're going to MITM despite potentially pissing off those who are fine with trusting their employers/coworkers. But I'm relatively OK with a well communicated and disclosed TLS proxy for work networks.
And on that basis, you're prepared to throw such a tantrum as to hold up completion and adoption of a crucial cornerstone of protection for people who actually need privacy?
Interception of web traffic stops those threats.
Nobody is throwing a tantrum or compromising a cornerstone of security. You don't really understand the full scope of what you are talking about -- the "cornerstone of privacy" you speak of is really placing ultimately trust in every random web service.
TLS and the root trust problems associated with it are bad enough. Preventing users from making choices about who and what they trust makes those problems dramatically worse.
No, but you stop that by refusing to let the printer talk out of your network at all.
> Or notes used by a police investigator while researching a unsubstantiated or even false accusation leaking thanks to some drive by malware?
That's where on-host monitoring can protect you. It'll also protect you in case that computer can ever connect to any other network.
That's a lost battle, honestly. If you block traffic from the printer to the internet, it starts sending UDP with faked source addresses.
If you deploy a VLAN the printer can fake the VLAN Tags. If you physically seperate the printer from any direct connection to your firewall, the printer can look for anything on the network it can use to bounce traffic from (like a DNS server or a computer accepting ICMP echo requests)
A sufficiently dedicated attacker can and will extract information through covert channels.
Whatever happens with TLS1.3, obviously the looming idiocy of the CA system is a larger problem. And yes, you're right, trusting random web services (ie, the other endpoint) is often a mistake.
But at the end of the day, the users that need to be served by TLS are the endpoints, not the proxy operators.
(FWIW, I suspect that TLS as we know it will shift fairly radically anyway as distributed applications become more prominent).
Do you ever go through your proxy logs and when was the last time you actually found something suspicious?
Even very sophisticated large tech companies don't epoxy their USB ports on their employee macbooks.
// EDIT: They also cover their asses with some 'network use policy' that is the vaguest possible thing and which even most software engineers don't understand the full extent of what is done. It's pretty disgusting, and I can't wait until some combination of GDPR style informed consent and what is law in austria[1] is put into employment law.
[1] https://www.taylorwessing.com/globaldatahub/article_austria_...
Place I work does this - and it's a constant PITA that gets in the way of me doing my job. But I think if you have a system to put exceptions in place, and it doesn't take 47 weeks of email ping ping with 18 different managers, then it's fine.
Unfortunately, where I work is a beurocratic nightmare.
But it's easily gotten around - I have a cloud-hosted VM (paid for by company MSDN!) that runs SSH on port 443 - so the HTTP proxy will let me through to setup a tunnel through which I can access anything using SOCKS.
I think assuming you can control any packets that pass through a network ends up being a losing proposition. Why not use things like VPNs to ensure that traffic to sensitive internal services is controlled? Failing that, install software on users computers and don’t allow them to use any non-work internet resources.
That's all well and good, but you don't need to do it from your desk at a regulated financial institution.
>I think assuming you can control any packets that pass through a network ends up being a losing proposition.
This is a very strange statement. All security is always a losing proposition. The best anyone can ever hope for is raising the bar of cost and sophistication an attacker will have to surmount to be successful, but you're still very much obligated (legally, and ethically) to do that. If you possess sensitive data, you need to take steps to detect and prevent exfiltration. If you have employees (such as registered broker-dealers) whose conversations with the outside must be monitored and retained under the law, you need to make sure they're using only the properly configured communication channels.
>Why not use things like VPNs to ensure that traffic to sensitive internal services is controlled
Because TLS interception is about preventing unwanted egress/exfiltration from the (relatively) trusted zone of a corporate network.
>Failing that, install software on users computers and don’t allow them to use any non-work internet resources.
Installing the corporate CA on managed endpoints is a prerequisite for TLS interception. The problem VPNs solve has nothing to do with this.