[AviationAtom]

I do understand the pain when it's a public one, but in corporate land it really does make big difference for security.

If you have the funds the Deep Packet Inspection is a big way to defeat attempts to tunnel through HTTPS, DNS, or the like.

[zamadatix]

Only if you SSL inspect which is a god awful maintenance/support burden even if you already have full control of every system which accesses the web from your network (pretty much excluding any usable guest access otherwise that becomes the next hole). There are definitely places that level of security make sense to maintain but typically as a requirement not something someone wants to do.

Even then you haven’t really solved that particular issue as it’s a people problem not a tech problem. It’s like trying to stop an employee from robbing the bank by getting a thicker vault door in that it’s just not the right type of incentive/disincentive to make an impact.

[MayeulC]

There are also countless ways to evade this: iodide (tunnel over dns), encapsulating encryped traffic in non-encrypted http, etc.

DPI just makes it harder, so does terminating ssl earlier, or blocking outbound ports.

[lxgr]

> in corporate land it really does make big difference for security.

When measuring security by "number of boxes checked", yes. Unfortunately, these boxes are often overly generic, years too old, or both.

> If you have the funds the Deep Packet Inspection is a big way to defeat attempts to tunnel through HTTPS, DNS, or the like.

What's there to inspect (unless you are decrypting all TLS in a middlebox with a root CA trusted by all clients)? How would you distinguish a "normal" WebSocket connection (as used by many sites these days) from a tunneled SSH connection, for example?

If you generally want to allow your users to reach the broader public internet (or even just web), this approach seems completely futile.