Hacker News Reader

Comment by nimbius | Hacker News Reader

"Middleboxes" is a pretty chicken shit definition of what are essentially appliances that, at best, allow companies to spy on employees and at worst enable despotic governments to target and crush dissent. My security should not have to wait for the devices that seek to violate it.

View on HN

Most of these middle boxes aren't actually man-in-the-middle attacking TLS. Instead they are enforcing aspects of the protocol, as some kind of Firewall. Sometimes this is silly fluff, preventing the bit-torrent protocol from running over port 443.

But sometimes it is useful: after HeartBleed I wrote a TLS inspecting firewall that blocks heartbeat records and I know it really helped get some customers out of a deep hole (they were unable to upgrade the impacted software itself).

Often it is something in the middle; like firewalls that look at SNI and X509 certificates to block "bad" domains associated with phishing and other abuse.

"Spy on employees" = Monitor the network activity of a sensitive, private business network.

I'll give the same spiel I give every time proxies come up: I am a donor to EFF, friend of privacy and the 4th amendment and I love the ACLU. I also recognize the legitimacy and importance of MITM proxies that inspect the content of SSL on a corporate network. It's not despotic to deploy company assets with company root CA certs that proxy TLS traffic to make sure a random employee isn't uploading credit card data to Box.

> make sure a random employee isn't uploading credit card data to Box

Except you aren't making sure, and there are many ways sensitive data can be exported. Let's be honest with ourselves here, these measures are often implemented under the guise of security but really are just liability and risk reduction approaches. The practical security benefit is very low IME, especially considering the burdens these measures put on employees' ability to work their best (and, as this article points out, burdens on others as well).

Which is harder for a call center employee or server admin?

1) Upload a file via GDrive or Box 2) base64 encode the data andsend it to a remote DNS server over the course of several days via TXT record requests

As another poster says, it's all about reduction of risk. It's about balance. And on a corporate network that owns the workstation and server configuration, running a root CA cert and installing it in a gold load is pretty easy for the level of inspection and prevention it provides.

This is not the end all of security, either. It's one of many steps.

I think it's mostly security theater without significant benefits. There are many parallels with the TSA here. It's not about ease of implementation as much as it's about employee trust. We shouldn't pretend that it doesn't also scoop up personal communications. Or you can say absolutely no personal communications using the computer you use for 8 hours a day if you're that type of person. Many SMBs survive without these measures, yet somehow they're sold as requirements by those with IT departments and the means. I hope "byopc" and remote work become more popular.

>Or you can say absolutely no personal communications using the computer you use for 8 hours a day

Exactly. It's a company resource. Most people seem to have / can afford a mobile device with cel/Wifi connectivity. Why should you feel so privileged to go to reddit, Gmail, Box, etc. on a bank network?

Email attachments and a few other mediums account for almost ALL nonmalicious leaks and MOST malicious leaks. Seems pretty good to me.

>Let's be honest with ourselves here, these measures are often implemented under the guise of security but really are just liability and risk reduction approaches

This is a fundamental misunderstanding of security. It is ALWAYS about risk and liability reduction.

Defensive infosec is mostly "liability and risk reduction." Why is "risk reduction" seen as a bad thing?

It isn't always, but when it is, it's because the costs outweigh the benefits. Usually this is in the form of lack of employee flexibility to do the best for the company (i.e. red tape and hoops become an impediment). However, in this case the cost is employee privacy. You might argue that they have none and spying on all traffic is reasonable, but many times these policies encourage employees to use workarounds that are even more dangerous just so they can have a modicum of privacy (e.g. alternative and less-vetted software packages, non-company hardware, etc).

Having worked defensive infosec for almost 2 decades, the privacy-invasion-leading-to-insecure-workarounds is not my experience. (US-based, I'll grant. I'm sure my experience would be different in Germany, for example.)

As long as the inspection was transparent (which it was until the TLS 1.3 discussion started), employees mostly didn't know they were being monitored, and they didn't care even when they learned they were. Folks who got caught downloading porn or running their side-business over the work network were surprised that we were looking for that stuff, but no one felt like their privacy had been violated.

I wish browsers would visually distinguish between the vanilla trust store from the OS or browser vendor and the current trust store as may have been altered by the system owner. Maybe the API to various certificate stores can't tell you this? But in practice there's probably some certificate qualities that are "really really good" at indicating where this connection is trusted on this computer but would not have been trusted by a newly installed Windows/macOS/linux/firefox/chrome system.

If you are going to spy on me, please disclose when and where. AFAIK w/HSTS sites they generally don't interdict the traffic (not because they don't want to but probably because they can't).

HSTS only says connections must be encrypted, not with which cert... you're thinking of a CAA record. Although a CAA record doesn't mean much if your adversary controls the DNS server.

I think you're thinking of HTTP Public Key Pinning. A CAA record just tells a CA whether it is permitted to issue certificates for a domain.

Well actually I think you mean... no just kidding. Thanks for the correction. I thought CAA records would also tell clients if a trusted root was also trusted for that domain.

Data Loss Prevention solutions are the only class of security products I can think of that attacks the problem in a worst way than antivirus do... That's say a lot.

All the time spent implementing those "solutions" would be better spent deploying proper access control, so that retards that may inadvertently upload confidential data to box don't have access to the information in the first place. As a bonus, it also protects you better from malice and not only stupidity.

> to make sure a random employee isn't uploading credit card data to Box.

or the PDF they clicked on

I think middleboxes also just includes network load balancers. A lot of places do TLS termination at a load balancer and plain HTTP inside the data center. These load balancer appliances are probably where a lot of these issues come up. And they aren’t there to spy on you.

Load balancers tend to be used on the server-side though, where the servers behind the load balancer serve web API's and such. It's fine if a TLS tunnel terminates at the edge of your private network if what's behind it is aware of this — i.e., the servers within the network serve plain HTTP by design and delegate transport layer security to the load balancer. TLS 1.3 doesn't break this.

These middleboxes are a way to spy on HTTPS connections between browsers and servers (where server can mean the load balancer at the edge of your server cluster), without having to ensure every device on the local network has a set of spyware installed on it.

Reply on news.ycombinator.com