Hacker News Reader

Comment by Spooky23 | Hacker News Reader

I should absolutely be able to intercept TLS traffic on my computers on my network. That's the distinction. Third party interception capability needs to be illegal and connections should be tamper evident.

Frankly, I have a higher duty than user privacy. My users have access to data that's critically sensitive in various ways, in some cases they face criminal sanction. I need to both control and detect unauthorized software on the network and ensure that users are following the rules.

More extreme privacy activists will make noises about things using endpoint based solutions or something similar. It's a bullshit position that will ultimately weaken security.

View on HN

The largest ISP in Kazakhstan believes that it should be able to intercept all TLS traffic on their network: https://bits.blogs.nytimes.com/2015/12/03/kazakhstan-moves-t.... Because there are no technical differences between your TLS interception and what Kazakhtelecom is doing and no legal differences in most non-Western countries, I believe that all software should be changed to make TLS interception as hard as possible.

There is absolutely a significant legal and moral difference between national interceptions like Kazakhstan does and the ones we do protecting children you are guardians of or protecting company secrets and integrity.

In the latter case ideally (and possibly legally required) you'd have acceptance of potential interception a condition of employment.

That isn't a technical problem, it's a Kazakstan problem.

On your computers, yes. On your network, not so much. You have no right to intercept data just because you are moving it from one side to the other.

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.

Yeah, no. The network is my property and the contract our employees or partners sign establishes terms for using the network.

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.

What your saying doesn't really address the issue marcosdumay raised: That is, the issue with allowing this kind of introspection is its susceptibility for abuse.

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.

Is setting up a private CA even enough with certificate pinning?

You should have a private CA setup if you're doing TLS inspection, I have one at home deployed through group policy/apple configurator profile to filter web traffic on any system my daughter is logged into (she's five and plays games on pbskids.org and such, need to make sure she can't even accidentally get at inappropriate content if I step away for a couple minutes to get lunch prepared or something).

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.

Come on man, be reasonable! If someone's boss saw that you were able to set this up for one user, in your spare time, that boss might think someone should just network-admin up and do the same for their organization. You know, rather than trying to break standards so they don't have to update the shitboxes they were silly enough to buy...

Oh gosh, network admins might actually have to learn how to do their job, or, more likely, managers might have to learn how to listen to them? The horror!

Re kids, might it be easier to whitelist sites instead?

Makes it harder for my wife to introduce her to new things, if I used a whitelist she would have to pester me any time she wants to get her onto a new site and then there’s the PITA of dealing with CDN’s and other third party sources that can change on a whim.

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.

Could you make a whitelist that, when faced with a site not on the whitelist, serves up a webpage that asks for the parent to enter a passphrase to add this site to the whitelist?

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.

> Could you make a whitelist that, when faced with a site not on the whitelist, serves up a webpage that asks for the parent to enter a passphrase to add this site to the whitelist?

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.

Your setup sounds really interesting! Do you have a writeup somewhere?

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.

The HTTP Public Key Pinning specification says that browsers should/may (I forget which) ignore the pin if the chain ends up at a private locally-installed CA, for this very reason.

It's also worth mentioning that an MITM proxy with a private CA root certificate could just strip HPKP headers out of any webpage it sends you. If your computer is tied to its network (e.g. corporate PC) it will never see it, so there's no issue.

I'm confused, isn't this the normal criterion for a certificate being valid? If your certificate chain doesn't end in a locally-installed trusted CA then how is that any different from a random cert signed by a nobody off the street?

As tscs37 explained, there's a difference between the CAs that came with your OS/browser by default, and ones you have installed. Pins are usually ignored if the chain ends at the latter, because that's exactly the sort of scenario that would be used for corporate TLS MITM.

There is a difference between a local CA and a CA part of the root store and/or as part of the system's CA bundle.

So terminating in a root CA imposes more restrictions than terminating in a non-root CA here? Something about that seems off...

Not root CA. Root store.

A root CA that has been installed by the computer administrator is assumed to be more trustworthy than the one installed by your OS.

This feels like it comes down to values more than security. Bottom line is you are intercepting my traffic as an employee.

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.

> It places trust in my employer and other employees (most of which I will never meet) that I'm not willing to give.

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.

> Yeah, no. The network is my property and the contract our employees or partners sign establishes terms for using the network.

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?

So you're ok with a compromised printer leaking your medical records? Or notes used by a police investigator while researching a unsubstantiated or even false accusation leaking thanks to some drive by malware?

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.

> So you're ok with a compromised printer leaking your medical records?

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.

>No, but you stop that by refusing to let the printer talk out of your network at all.

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.

Yeah, I mean it really depends on the brass tacks here.

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).

All you have to do is block all TLS on your network and you're good to go.

Do you really think a silly proxy will deter an evil employee from getting data off your computers? There are a miriad of other ways to extract data: usb stick, WiFi hotspot from your 4G phone, bring the whole laptop home or simply obfuscate/encrypt the data and tunnel it over something that looks legit.

Do you ever go through your proxy logs and when was the last time you actually found something suspicious?

Epoxying the USB ports and locking in the network connection settings with Group Policy are par for the course in the kind of organization that would implement TLS interception.

Nope, they don't. Most organizations I call the 'casual creeps'. They buy some badly made security appliance or software suite, install the certificate through some active directory policy and call it a day as their IT staff snigger behind the scenes at whatever their employees are doing. If they made their creepy behavior more public, they will rightfully so start getting higher employee turn over.

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_...

Yeah how could they sell their used laptops when they upgrade, if there were epoxy in the ports? I've never heard of any named non-military organization doing that. You're totally right about the network creepers, too. They're easy to spot: just point out some of the problems with proxy shitboxes or the ridiculous EULAs that come with them and see who gets pissed off.

So true, I've worked in tons of places with proxies but zero with epoxied usb ports or locked down network configuration. The only thing these proxies ever achieved was lower productivity due to hours of configuring custom software or not being able to browse useful information on legit sites like stackoverflow. It's just a play from IT so they can add a tickbox saying their network is secure when in fact it's a big fat joke as these proxies usually act on a blacklist basis and not whitelist.

> You cannot get out of the network unless the traffic is proxied

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.

This seems like such an old fashioned way of thinking. Internet access is increasingly a fundamental human right and is needed to interact with most government services in first world countries.

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.

>Internet access is increasingly a fundamental human right and is needed to interact with most government services in first world countries.

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.

TLS interception is predicated on whitelisting your own CA on the endpoint. Can't really do that if you don't manage it. And in any case, you need to be resilient to a rogue or compromised device.

> I should absolutely be able to intercept TLS traffic on my computers on my network.

Just ask the users of your network to install your CA cert (or click past your cert warnings). That should work with TLS 1.3 right?

Or in your statement are you really meaning, "I should absolutely be able to intercept TLS traffic on my computers on my network without them knowing about it"? If so, that's a completely different thing altogether and if that's what you and the GCHQ mean when talking about proxying, it needs to be explicitly stated. There is a huge difference.

> I should absolutely be able to intercept TLS traffic on my computers on my network. ... / Frankly, I have a higher duty than user privacy. My users have access to data that's critically sensitive in various ways, in some cases they face criminal sanction. I need to both control and detect unauthorized software on the network and ensure that users are following the rules.

Perhaps the security agencies view their country as "my network", and then if you read the rest of the quote, everything follows from there.

There are big differences: The compulsive power of government, and the necessity of civil rights and peacefully organizing against the government; compared with the 'at will' relationship with a company and its interest, generally considered legitimate, in ultimate authority and stopping insubordination.

On the other hand, large companies are not really 'at will'; people can't just walk away from jobs 'at will', especially when they have children, mortgages, other debts, or (in the U.S.) health problems. Also, some insubordination is legitimate: Labor organizing, legal and regulatory complaints (EEOC, safety, etc.), and probably other things I'm not thinking of.

The distinction isn't so clear cut. I'm not sure the objection of the corporate sysadmin is that much more valid than the government security agency. Also, the security agency often has far more at stake.

TLS 1.3 doesn't change that, you can still MITM connections using your own root CA certificate installed on users' devices. Not quite sure what you're arguing against here.

You're saying with a straight face that you want to have encryption containing a backdoor. How is your demand different from the FBI's and its ilk?

Intercept the traffic on your machines, if that's a legal requirement.

Let's say a user has to access something confidential over your network to an outside resource that has to follow HIPAA guidelines.

Intercepting that data would be an HIPAA violation, how do you avoid that?

Do you have a citation for this? I do security reviews for companies with strong HIPAA requirements and I’m nearly certain this is incorrect.

We properly presume your network to be hostile and malicious to security. You've declared it so. Therefor everything is encrypted and secured. Your hostile network is no different than a hostile network of a small country bent on attacking the security of the communication.

So feel free to have insecure communication provided you control all devices on the network. It will still be insecure.

Reply on news.ycombinator.com