Comment by tolien | Hacker News Reader

Comment by tolien | Hacker News Reader

Parent Full thread

https://en.wikipedia.org/wiki/Middlebox

The nature of TLS is that nobody in the middle is supposed to be able to read what's encrypted, and that either end can detect if traffic they receive has been modified in transit.

Of course this is incompatible with corporate (especially financial) networks where employers have legal/compliance/noseyness reasons to want to make sure their employees aren't doing things they shouldn't (sending corporate secrets to the NYT, having their corporate knowledge siphoned out by malware, spending all their time on Facebook etc.), and repressive regimes (where, for example, Erdogan wants to know if you're a member of the Gulen movement) - Bluecoat and Cisco, for example, do a lot of business in the Middle East and China.

They'll typically act as a man in the middle for TLS traffic, re-encrypting traffic using either a compliant root CA or a corporate CA that all employee machines have been made to trust. The nature of Enterprise Software is that these devices will have poor, incomplete or outdated implementations of TLS with the result that, for example, a lot of them didn't know what to do with draft TLS v1.3 traffic and just dropped it on the floor as invalid.

I'm not buying the argument that middleboxes are incompatible with corporate networks. The IT staff can install their own root certificate on all machines, and then they can decrypt all the traffic they want. What about HSTS? IT can disable that (they have full access to all machines anyways). What about personal devices? Those should connect to a separate network.

In essence: if corporate wants to spy on me, they shall provide me with devices that are set up that way, and with that I know I can't have any expectation of privacy. If I'm using my own device, I want TLS to actually provide security and confidentiality. If that means denying my personal devices access to the corporate network, so be it.

Yeah it is a super dumb excuse. The real reason is this:

> Our IT team is going to have to do some work and expose that traffic is sent unencrypted (or differently encrypted) to the final hop on the network.

I get why IT teams don't want to, especially for huge organizations, but "lol we can MITM TLS" is not acceptable. Terminate the exterior TLS at the network, inspect / log it, then re-black it to the end device.

Also, I want to take a second to complain about locally installed certs. I know we all know how they work and everything, but most users don't. The fact that I can see a green lock for google.com when Eve has put a local cert on my machine is really stupid.

People check their personal email on their work computers, that's just a fact of life. Their personal email password shouldn't be in some network log somewhere without them understanding that this is possible. There should be a different colour for when trust is different. A blue lock, for example. I know IT has root anyway, but most companies don't install key loggers on their gear or do obviously shady shit, and I think it would benefit users to have a clear demarcation about who they are trusting.

Well, they should install keyloggers. Okay, not keyloggers per se, since they are pretty useless, but if you control the software on the device, you can monitor internet activity in a million and one ways, none of which involve breaking the internet.

Looking at the Lewandowski stuff, that's what Google does. And for obvious reasons. Just logging internet traffic isn't very useful at all for compliance.

It isn't clear to me that that is what Google does, and installing a keylogger without informing employees is shady, no matter how you dice it. The network makes sense, but people "think outloud" while they revise draft emails. They change their mind on resigning or sending a harsh email. Big difference.

I like this idea of different signals for different levels of trust. In practice how would it be best implemented though? Some sort of entry in DNS that says "we have all certs signed by one of these two CAs" and then clients could see if a cert is valid but chains up to a different root and show "this is secure, but not in the way you think"?

Basically, yeah.

And maybe it should be country-smart too. An HTTPS cert originating from China and being used for a Chinese service is green, but as the internet balkanizes we may want to be a little smarter. Not sure on that though.

>People check their personal email on their work computers, that's just a fact of life.

Well, that's their dumbass fault.

At our company, there is a giant warning on the login screen that "You are using a corporate asset and there is NO expectation of privacy."

Now, as to the safety of browser locks... sounds great until the company patches their Firefox distribution.

I didn't mean that middleboxes are incompatible with corporate networks, but that TLS's design of "your traffic is encrypted and nobody between Alice and Bob can read what they say" is. Middleboxes are a workaround for that.

As you say, there are other issues in a BYOD environment but is that common in an environment that uses middleboxes anyway?

The problem with middleboxes and TLS v1.3 wasn't that IT can see you're on Google, it's that you go to Google and get a grey page that says LOL_SSL_ERROR.

>The problem with middleboxes and TLS v1.3 wasn't that IT can see you're on Google, it's that you go to Google and get a grey page that says LOL_SSL_ERROR.

More like, everybody is offline as the middlebox crashed. Which is how it should be: Garbage in the network path should be highlighted and removed.

>If I'm using my own device, I want TLS to actually provide security and confidentiality. If that means denying my personal devices access to the corporate network, so be it.

That's how middleboxes work already. How could they work any other way? If you don't install the root certificate on the client machine TLS fails as it should. You'd need some generally accepted CA to issue a wildcard certificate for the whole internet if that wasn't the case. Has anyone actually done this?

As I recall there was a CA that either after external compromise or via a rogue employee issued a cert for *.com at one point. But it is definitely not something any respected CA would do willfully.

And that's a quick way to get the big root stores to start looking very, very closely at you.

It’s not that they can’t do it correctly but that enterprise IT controls a lot of systems and operates on near-geologic timescales. If you want TLS 1.3 deployed you either need to convince a ton of vendors to reverse their custom of charging $$$ to fix their buggy appliances or wait a decade for everyone to finish buying newer less-slow, less-buggy appliances.

Third option: You deploy TLS 1.3, the middleboxes break, but that's neither your fault nor your problem. Hopfully they're makers or users will learn from this and not make respectively buy broken garbage. All major browser vendors appear to be involved with TLS 1.3.

Exactly, why should the whole web suffer just from the shitty internal practices of some large companies. If their trashcan ready hardware is breaking TLS, they can deal with the consequences.

Everyone seems to look at this from the "large corporations IT" and "mass surveillance" perspective, but let's not forget that everyone should also have the right to inspect and modify traffic on the networks and devices they own. TLS MITM is not necessarily a bad thing.

Do you know what traffic your IoT "smart" things and even your PCs and mobile devices is sending and receiving?

https://news.ycombinator.com/item?id=6759426

> where, for example, Erdogan wants to know if you're a member of the Gulen movement

Anti-Gülenist cleanup has been completed. It is now the time to appeal and correct the mistakes.

Reply on news.ycombinator.com