0

As far as I have understood it:

  • An explicit proxy challenges the user/application within his session.
  • NGFW (transparent proxy) and SSO/identity-based solutions are just letting everything pass that is using the current IP address of the user.

I agree the latter is flexible with regard to roaming users (VPN, Wifi and whatnot) but IMHO similar to machine/IP-based authentication, i.e. a step back from actually challenging the individual application for access. (Note: if you use a captive portal, non-interactive apps will have a hard time authenticating.)

The transparent proxy would let all traffic from your machine go directly to the URL filter, including the potential malware. Whereas in the explicit scenario the malware would need to obtain the user's credentials, parse the PAC file or somehow else determine the location of the proxy to use etc. Might be considered security through obscurity, still more hurdles can't hurt... Additionally, a transparent proxy would require recursive DNS access to the Internet, meaning DNS security would need to be implemented. Whereas when using an explicit proxy, the client needs no DNS access at all, the proxy itself would perform a DNS request once the URL filtering/categorization or any other mechanism has allowed access.

Somehow I fail to see where transparent approach would provide more security than explicit. The more modern approach (NGFW/transparent) seem to rely more and more on blacklisting and heuristics, while we learned that actual security only comes from denying everything that we do not know i.e. whitelisting. I agree that this is difficult in today's Internet though. So which one is more secure, transparent or explicit, or does it only depend on the individual definition of security/risk?

2

Somehow I fail to see where transparent approach would provide more security than explicit.

It doesn't, in contrary. It is just more convenient to enroll since clients do not need to be configured explicitly. Security is usually a trade-off and the additional risks might be acceptable when gaining better usability.

From the security perspective an explicit proxy is the preferred solution since it is independent of the actual target port (NGFW needs to use DPI based heuristics here) and has no problems with multiple users on the same IP address (i.e. NAT, terminal server, ...). Additionally an explicit proxy bases its security decision on the proxy request, i.e. the URL (HTTP) or domain name (HTTPS) given there. And it is the proxy who determines the IP address of the target based on the requested domain name.

Contrary to this with a transparent proxy the client determines the target IP address1 and the transparent proxy passes the connection establishment through before being able to apply security checks based on the domain or URL. This can be used to bypass policies by simply claiming to connect to a whitelisted domain in HTTP Host header and TLS ClientHello SNI, while the actual IP address connected to is for example some C2 server.

The more modern approach (NGFW/transparent) seem to rely more and more on blacklisting and heuristics, while we learned that actual security only comes from denying everything that we do not know i.e. whitelisting.

This is not really a difference between explicit and implicit proxies, i.e. the policies they apply can be the same. Apart from very restrictive setups both usually rely on blacklisting and pass though most traffic. The target hostname lacks reliability though in case of the transparent proxy since the IP address is resolved by the client1 and not by the proxy. And lack of reliable input into a policy means that the policy decision will also lack reliability.


1 As Mike Ounsworth pointed out in his answer this can be avoided if the DNS server is in control by the company too and simply returns the IP address of the proxy. This isn't though how most installations are set up.

1

You've thrown in a lot of buzzwords that I think are un-related to the core question of (I think?) authentication differences between the two proxy modes "explicit" and "transparent". First, definitions: quoting the Alpine / Squid proxy docs:

explicit forward proxy

An explicit proxy is one in which the client is explicitly configured to use the proxy, and as such are aware of the existence of the proxy on the network. ... Connections to HTTPS sites through an explicit proxy will use the CONNECT HTTP method.

This means that you client (for example a browser) needs to know that it's using a proxy, and instead of GET / POST, etc, it sends a CONNECT HTTP header that tells the proxy which host it is actually trying to reach.

transparent forward proxy

A transparent proxy, also known as an intercepting proxy, does not require any configuration changes on the client ... When the client sends packets, they are addressed to the destination server.

Typically in this mode you would set up the proxy, for example, so that all traffic it receives on :8081 will get routed to example.com:8443 and the proxy also usually replaces any host headers in the original with the destination host. This is transparent because the client (ie browser) does not know that it is talking to a proxy.


Whether your proxy is configured as explicit or transparent is orthogonal to how you do authentication concerns. You can have a transparent proxy that requires HTTP Basic Auth header or TLS client certs which is consumed by the proxy and not forwarded to the app server, and therefore has exactly the same security properties as the "explicit" proxy you are describing. You could also have an explicit proxy that does SSO, so I really don't think this has anything to do with the proxy mode.

Additionally, a transparent proxy would require recursive DNS access to the Internet,

I don't think that's right. With a true transparent proxy, the client's DNS for example.com needs to return the IP address of your proxy, which is the same requirement as for an explicit proxy, no?

Anyway, I feel like your question is specific to the proxy vendors you are working with, and not a general question.

2
  • "You can have a transparent proxy that requires HTTP Basic Auth header" - while in theory the transparent proxy could stop the original request and return 401 to claim that the target web site requires authentication, the client would need authenticate against each new target site and prompt the user for it - which I would consider unusable. This is different from entering the credentials once when authenticating against an explicit proxy. Similar problems are with client certificates. Typically a temporary redirect is done instead to a fixed server in order to avoid this problem. Apr 19 at 16:55
  • "With a true transparent proxy, the client's DNS for example.com needs to return the IP address of your proxy" - good point. This also avoids the problem I've mentioned of faking the target by faking the Host header and SNI while actually connecting to a different IP. But in practice I think most transparent proxies are not set up this way. Apr 19 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.