How would you assess the added value of web security gateways/proxies in days of > 90% of all traffic encrypted?

Question

As of today, web security gateways add a layer of complexity to corporate web traffic while - in my opinion - only adding a small layer of protection, as most web traffic is encrypted nowadays.

Of course, it's - as of now - possible to MITM the encrypted traffic, but that has additional drawbacks in fact - again in my opinion - does not add a layer of security but removes one.

Is there anything I am missing from a security point of view or do those things still sell primarily because some compliance regulations require them?

Answer 1

.. possible to MITM the encrypted traffic, but that has additional drawbacks in fact - again in my opinion - does not add a layer of security but removes one.

True, MITM taken only by its own does not add a layer of security and instead weakens it. But security solutions do not simply add MITM for nothing, they add it to inspect the content. And this content inspection again adds security, like it does when inspecting plain HTTP traffic w/o encryption. In many cases the security gained with content inspections outweighs the weakened security due to trusted(!) MITM.

This content analysis is especially relevant to detect unwanted downloads or data leakage like credential phishing. It might also be useful for detailed logging in order to track down the cause of incidents later or to detect C2 traffic.

Blocking whole domains instead can usually be done without MITM, either by analyzing the server name (SNI) in the TLS ClientHello or by analyzing DNS requests. Newer approaches like ESNI (Encrypted SNI), ECH (Encrypted Client Hello) and DNS over HTTPS or TLS can make such less invasive analysis harder though.

Further analysis without MITM can be done using TLS fingerprinting and traffic pattern analysis (direction, size, timing ...). This provides less visibility than MITM, but might for example be useful to detect non-browser traffic, like malware communication.

None of this provides perfect security though. And many of this analysis can be bypassed with sufficient effort and knowledge. But compared to simply let all traffic pass through without observation it still provides valuable security.

Answer 2

There are two level of web security gateways. The outer level prevents any network access to the inner network that contains the web servers and other application servers like the database except for the HTTP/HTTPS traffic. That part is specifically encapsulated there, which allows to easily and quickly ban some domains or address classes without disturbing the main server. It can also help to limit the load on the main servers.

There can also be an inner level which is often implemented on a different (virtual) machine. That proxy decrypts the TLS layer and performs a minimal validation on the request formats to only pass valid requests to the application server. The rationale behind is that this proxy uses an application like nginx or Apache which are much simpler that a full application server and because of that is expected to be much less vulnerable to specifically forged anormal requests (for example too long or inconsistant request elements).

It indeed adds administrative tasks but is intented to reduce the attack surface on the application servers which are large programs that cannot be expected to be as exhausively scrutinized for implementation flaws as smaller tools can be. Whether it is worth it depends on the real use case. If you cannot afford proficient network and proxy admins, it may of course be a bad solution, but if you can it is generally seen as more secure.

Answer 3

As pointed out by others a proxy for TLS interception might increase your security. However, it can also decrease the security. If the private key for the proxy gets stolen the attacker could read and modify the traffic for all devices which use the proxy. So they are a valuable target and actively attacked: https://www.schneier.com/blog/archives/2019/11/the_nsa_warns_o.html Having attacks like heartbleed in mind you maybe won't ever notice something was stolen. Even if the attackers needs to get into the system, you need to actively look out for it. He just needs to steal the key, cleanup and leave. I'd very much recommend a HSM.

The proxy software might be less maintained than your client application (of course it might also be the other way around). The proxy maybe can't handle certificate transparency or pinning. Most proxy software is just some Linux + squid + GUI. Many providers have a long list of security advisories ... In rare cases they came up with some homegrown solution for TLS inspection (OS still being Linux)
A proxy will make it clear to anyone on the network or remote end that you are using a proxy and maybe even which kind of proxy software you use. Since such proxies are an interesting target, the people/companies creating them are too. So you should hope it won't become the next SolarWinds.

Answer 4

Even if your proxy isn't doing TLS decryption, it can still (usually) see the domains that users are connecting to. So while it might not be able to see exactly which page on badsite.com they're accessing, if you want to block the entire site then that's not an issue.

This won't always be the case (such as if ESNI is used), but will still provide some level of filtering.