Can the WSA forward HTTPS to another proxy using routing policies?

[jkirby]

We have an IronPort S160 version 7.1.3-021 for Web  configured as a transparent proxy.  We need to forward LinkedIn, Twitter and Facebook to an Actiance proxy for social moderation.  This works for all HTTP traffic but does not work for HTTPS.  If I watch the acess log I can see the HTTP transaction and I also see our custom routing policy and everything is fine.  However when I request the same site over HTTPS, I don't see every transaction in the access log and I also don't see the routing policy in the policy chain in log entries that do appear.  I've adjusted the filter on the routing policy but HTTPS traffic still goes direct while HTTPS goes through the upstream proxy.

Is the WSA able to forward HTTPS requests to another proxy using routing policies?  If so, can someone show me how?  Apparently my skillz are lacking here.

[Erik Kaiser]

Hi jkirby,

You will need to set up a decryption policy on the WSA in order to be able to see requests made via HTTPS. Log into the GUI of the WSA -> Web Security Manager -> Decryption policy -> You can set the Global Policy to Decrypt Social Networking. Or you may create a new Decryption policy and determine which categories you would like to decrypt, drop etc. Decryption policies are very similar in how they work as compared to access policies. The difference is that the traffic is encrypted.

Sincerely,

Erik Kaiser

[jkirby]

I wish it were that simple.  The routing policy and the decrypt policy are triggered on the same custom URL category and user group.  Yesterday I added this category to the global decrypt policy and tried pass through, decrypt and monitor but none worked.  After seeing your reply I tried again this time creating a custom decrypt policy that is just above the global policy.  Still not working with any decryption setting.  The Global decrypt policy for Social Networking has always been set to decrypt.

Here are two log entries that show the routing policy is not being triggered for SSL.  The first log was when I hit a LinkedIn profile page.  The second log is when I simply added HTTP:// in front of the URL.

1337789276.036 3692 10.54.2.241 TCP_MISS/200 186078 GET  http://www.linkedin.com/ "META\jkirby@Meta" DEFAULT_PARENT/172.30.200.100 text/html DEFAULT_CASE_11-Meta_Social_Networking-Meta_Authentication-NONE-NONE-NONE-Meta_USG_Redirect -

1337789329.511 750 10.54.2.241 TCP_MISS_SSL/200 30911 GET  https://www.linkedin.com:443/

"META\jkirby@Meta" DIRECT/216.52.242.80 text/html DEFAULT_CASE_11-Meta_Social_Networking-Meta_Authentication-NONE-NONE-NONE-NONE -

Notice the difference in the policy chains?  The last policy on the HTTP request is "Meta_USG_Redirect", our routing policy.  However there is no routing policy applied to the SSL request. 

[rafasdkcisco]

Hi, any solution ??

[sfiebran]

In transparent environment, routing to upstream proxies is only supported if you would route all traffic to the upstream proxy (with a global routing policy). This is an underlying limitation as within HTTPS transparent request the requested domain details aren't available yet while the desision has to be made. Therefore the WSA will connect first to the target IP to determine the HTTPS hostname via its certificate. At this time its actually already to late to decide to take which route. If you do the test again with an explicit request, it should work. This would be also the only feasible recommended workaround to use explicit request for those HTTPS url's that should be pushed to another upstream proxy.

The major issue is, that you can't convert a direct (transparent) request from a client to a https proxy request without to loose anything. For this reason, the explicit CONNECT feature is used for HTTPS to work with proxies properly.

Hope I could explain a bit more the situation.

-Stephan