I'm trying to better understand how the transparent common name handling option (in the Proxies section of the configuration where HTTP proxies can be configured) works.
As I understand things, in a mode that = Transparent Proxy, this setting should be set to true so that MWG can create a cert with a common name that uses the common name of the certificate presented by the remote site rather than using the destination IP address.
If you have proxy configuration that web browsers explicitly proxy to, it's not going to be a transparent connection. How does setting transparent common name handling affect those connections?Message was edited by: Ex_Brit on 08/02/13 11:12:29 EST AM
I am not 100%ly certain but I think that explicit proxy connections are not affected by the setting. The setting is used to obtain the hostname which is not required in explicit proxy mode, since the CONNECT request contains all the information required to obtain the hostname.
Andreon 08/02/13 11:12:50 EST AM
the setting "Transparent common name handling for proxy requests" applies ONLY to proxy requests and does what was stated in this thread:
>MWG can create a cert with a common name that uses the common name of the certificate presented by the remote site rather than using the destination IP address.
The purpose is to avoid the common name mismatch if you have an other network device that intercepts port 443 and redirects it to MWG and uses the destination IP in the CONNECT header.
Janon 08/02/13 11:13:12 EST AM
Another situation where transparent common name handling would be key is if the connections are being handled by WCCP.
Is there any significant negative performance impact associated with having that feature set for a proxy which is only used for direct proxy? I suppose it would depend on how the code is written, but if every connection to the direct proxy triggers a routine that checks to see if transparent handling is enabled and then performs the task of grabbing the common name of the certificate presented by the remote site rather than using the original URL.Host destination, that could add overhead. If, on the other hand, the proxy code is written such that a direct connection to the proxy causes that logic to be entirely skipped, that's a different story.on 08/02/13 11:13:33 EST AM
maybe this will clarify some things. it was written by one of our main support engineers.
The issue with transparent https requests is that there is no CONNECT request like we have for direct proxy requests. So all mwg gets in the beginning is the destination IP. It then makes up a connect request internally and gets on its way with filtering. The proxy knows it’s a transparent request and fill properties for the rule engine to deal with it accordingly.
But if you have a setup, where something downstream (like our own sidewinder FW) is intercepting the transparent https traffic (also only getting the IP, not the hostname) and then generates a next hop proxy request to the web gateway, the web gateway gets an actual CONNECT request and thinks it’s a proxy request. But in the CONNECT you got the destination IP, not the hostname the user typed in the browser. So what you need is the same transparent treatment you get for wccp, even though it’s a legitimate CONNECT. That is what this infamous checkbox is for. It tells the proxy to treat a real CONNECT request like it was a transparent request and fill the same properties so that the rule engine can deal with it.
For those like me who can better picture this with a rule example, go ahead and import the default ssl scanner. When you expand the rule sets, you can find “Verify Common Name (Proxy Setup)” and “verify Common Name (Transparent Setup)”. The main difference is at what point in the rule processing the common name check is done AND the property Connection.SSL.TransparentCNHandling. This property is set to true in a real transparent setup (like WCCP) and/or in a direct proxy setup when the checkbox in the proxy for transparent common name handling is set.
So, if you set this in a pure transparent/wccp setup, it has no impact. But if you also have direct proxy requests, you definitely do not want this box checked, so that common name handling happens at the right time.on 08/02/13 11:13:54 EST AM
So, if I am understanding correctly, the appropriate way to implement for each proxy instance would be as follows:
WCCP only -- transparent common name handling = true
Direct Proxy only -- transparent common name handling = false
WCCP + Direct Proxy -- transparent common name handling = false
So if I have one proxy instance for WCCP and a second instance for direct proxy, it would follow that I check the box for the WCCP instances, but ensure that it's not checked for the instances that only handle direct proxy requests.
Have I interpreted correctly?
Oh, also, if I have a proxy instance that is only serving direct proxy connections, I should de-select the Serve transparent SSL connections checkbox, right?
Message was edited by: btlyric on 2/7/13 6:19:58 PM CSTon 08/02/13 11:14:14 EST AM
That is my understanding.
Of course, i could be totally wrong too and someone in support should pipe up to refute that. Many of them watch this list.on 08/02/13 11:14:33 EST AM
I shall interject my two cents here....
But for everyone's understanding, the only time you would need to check the box for "transparent common name handling for proxy requests" is if you were using MCP (McAfee Client Proxy) or if you were transparently redirecting the traffic from a sidewinder. The "flag" is set automatically for WCCP traffic and trans bridge or router (from what I've been told).
All this checkbox does, is set a flag (Connection.SSL.TransparentCNHandling equals true) for the rule engine, so the rule engine handle's the request differently as it pertains to creating and performing certificate verification. See below screenshots for how its used in the rule engine (which you probably already saw):
Let me know if this helps. Jan, let me know if I am incorrect in my understanding of this setting.
Jonon 08/02/13 11:14:57 EST AM