I'm beginning to think that I had the wrong approach to a topic that I posted in a previous question (here), regarding Domain Fronting. Is there a way to compare the host name for a GET or POST to that of the CONNECT in which they are tunneled? The idea being to restrict GET's and POST's to the domain of the CONNECT, at least for those destinations with less trustworthy risk scores.
And, this brings up a related question: are the details in the SSL certificate from the CONNECT, particularly that of CN's and alternate names, visible to the tunneled GET's and POST's? If so, what would be a good approach to validate the current hostname to the CN and alternate names?
Solved! Go to Solution.
I found a good test for this as well as a means to detect it on MWG.
To test, here is a curl command which opens a tunnel for cnn.com, and once the tunnel is opened, requests are sent for mcafee.com instead.
curl --insecure -v -s -o /dev/null --proxy http://yourmwg:9090 -H "Host: mcafee.com" -H "Connection: close" "https://cnn.com/"
In the Web Gateway we can make use of the Connection.Variables.* events and properties to store the originally requested domain from the CONNECT request, and recall it once we're inside the tunnel to perform a test to see if the original domain matches the domain requested in the tunnel.
Now this might have some caveats, specifically related to transparent proxy. So by default these rules only apply to Explicit proxy requests. For transparent proxy requests, the MWG relies on the SNI header in order to determine the originally requested domain, so if that is not present, then the MWG would only know the destination IP, and in most cases that will result in a mismatch.
Let me know if you have any questions on the rules and if this helps at all. At first it might be good to just monitor to these things, then block (in case there is false positives).
Best Regards,
Jon
The URL.DiscardedHost property was added in 7.8.2. From the interface reference guide:
URL.DiscardedHost | String |
Name of a host that was discarded when conflicting host names occurred in a request sent in HTTP(S) or SSL communication. A conflict of this kind is also known as domain fronting. It is resolved by the proxy on Web Gateway, which prefers one of the conflicting host names over the other, depending on what is configured. By querying the value of this property in the criteria of a rule or by logging it, you can detect a host name conflict. If no conflict arises, the value of the property is an empty string. Conflicting host names might occur in the following scenarios:
|
The proxy unifies the URL from the firstline and the Host header before the rule engine is called, this ensures that the policy decision is made based on the same data that the proxy is using to determine the destination. Whether or not the firstline or the host header wins can be configured in the advanced section of the proxy configuration.
The ruleset is not needed on versions after 7.8.2. Action (log or block) can be based on DiscardedHost property. “URL.DiscardedHost” will be filled if there was an instance of domain fronting that was allowed to override the firstline.
Attached is a much improved ruleset for detecting and blocking DF attempts using both the DiscardedHosts property and Connection Variables. The rulset saves the connected domain and compares that to the URL.Host domain of any subsequent GETs.
|
Hi John,
So, MWG has a configuration option called "Host header has priority over original destination address (transparent proxy", this prevents situations where there is a mismatch between the Host header and the Request line. 7.8.2 brings a property called URL.DiscardedHost which is meant to help detect Domain Fronting whereby you can access the host that was discarded from the scenario above.
For the scenario you described MWG would connect to the Host from the CONNECT request, and if inside the tunnel requests are made for separate domains, MWG would see those requests assuming that SSL inspection is enabled.
So if the CONNECT was for facebook.com, and you've got something making requests to malware.com (inside the tunnel), MWG will see those requests and treat them according to your policy.
Having said this I'm not sure if we'd have the "facebook.com" context available for the requests inside the tunnel (to make sure the hosts match). Did you have a script you were using to try and recreate this scenario? This might be something I could test really quick if you did.
Best Regards,
Jon
I found a good test for this as well as a means to detect it on MWG.
To test, here is a curl command which opens a tunnel for cnn.com, and once the tunnel is opened, requests are sent for mcafee.com instead.
curl --insecure -v -s -o /dev/null --proxy http://yourmwg:9090 -H "Host: mcafee.com" -H "Connection: close" "https://cnn.com/"
In the Web Gateway we can make use of the Connection.Variables.* events and properties to store the originally requested domain from the CONNECT request, and recall it once we're inside the tunnel to perform a test to see if the original domain matches the domain requested in the tunnel.
Now this might have some caveats, specifically related to transparent proxy. So by default these rules only apply to Explicit proxy requests. For transparent proxy requests, the MWG relies on the SNI header in order to determine the originally requested domain, so if that is not present, then the MWG would only know the destination IP, and in most cases that will result in a mismatch.
Let me know if you have any questions on the rules and if this helps at all. At first it might be good to just monitor to these things, then block (in case there is false positives).
Best Regards,
Jon
A bug was discovered in v2. Thanks Aaron. The v2 ruleset works if you enable the first rule and disable the second.
Or if you change the logic of the second rule to stop ruleset if Connection.SSLTransparentNameHandling equals true.
The URL.DiscardedHost property was added in 7.8.2. From the interface reference guide:
URL.DiscardedHost | String |
Name of a host that was discarded when conflicting host names occurred in a request sent in HTTP(S) or SSL communication. A conflict of this kind is also known as domain fronting. It is resolved by the proxy on Web Gateway, which prefers one of the conflicting host names over the other, depending on what is configured. By querying the value of this property in the criteria of a rule or by logging it, you can detect a host name conflict. If no conflict arises, the value of the property is an empty string. Conflicting host names might occur in the following scenarios:
|
The proxy unifies the URL from the firstline and the Host header before the rule engine is called, this ensures that the policy decision is made based on the same data that the proxy is using to determine the destination. Whether or not the firstline or the host header wins can be configured in the advanced section of the proxy configuration.
The ruleset is not needed on versions after 7.8.2. Action (log or block) can be based on DiscardedHost property. “URL.DiscardedHost” will be filled if there was an instance of domain fronting that was allowed to override the firstline.
Attached is a much improved ruleset for detecting and blocking DF attempts using both the DiscardedHosts property and Connection Variables. The rulset saves the connected domain and compares that to the URL.Host domain of any subsequent GETs.
|
New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.
Thousands of customers use our Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership: