Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
1156 Views 7 Replies Latest reply: Feb 8, 2013 10:03 AM by Jon Scholten RSS
btlyric Apprentice 184 posts since
Aug 1, 2012
Currently Being Moderated

Feb 8, 2013 10:12 AM

Transparent common name handling

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
  • asabban McAfee SME 1,357 posts since
    Nov 3, 2009
    Currently Being Moderated
    1. Feb 8, 2013 10:12 AM (in response to btlyric)
    Re: Transparent common name handling

    Hello,

     

    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.

     

    Best,

    Andre

     

    on 08/02/13 11:12:50 EST AM
  • jschnell Newcomer 26 posts since
    Jan 21, 2011
    Currently Being Moderated
    2. Feb 8, 2013 10:13 AM (in response to asabban)
    Re: Transparent common name handling

    Hi,

     

    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.

     

    Byxe

    Jan

     

    on 08/02/13 11:13:12 EST AM
  • eelsasser McAfee SME 843 posts since
    Mar 24, 2010
    Currently Being Moderated
    4. Feb 8, 2013 10:13 AM (in response to btlyric)
    Re: Transparent common name handling

    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
  • eelsasser McAfee SME 843 posts since
    Mar 24, 2010
    Currently Being Moderated
    6. Feb 8, 2013 10:14 AM (in response to btlyric)
    Re: Transparent common name handling

    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
  • Jon Scholten McAfee SME 856 posts since
    Nov 3, 2009
    Currently Being Moderated
    7. Feb 8, 2013 10:14 AM (in response to eelsasser)
    Re: Transparent common name handling

    Hi all,

     

    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):

     

    1_transcnhandling.png 2_transcnhandling.png

    Let me know if this helps. Jan, let me know if I am incorrect in my understanding of this setting.

     

    Best,

    Jon

     

    on 08/02/13 11:14:57 EST AM

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points