Wingate 7 let proxyserver also listen on 443

[jrosen]

I have made a proxy service, it works as expected so far. But SSL/443 gets thrugh all my white and black lists.
In "old wingate" i could also add port 443 to the service. Where is this in Wingate7?

(i know that the "lärare?" is not fully configured yet)

wingate.JPG (52.75 KiB) Viewed 10063 times

Next question, i have set up a rule that i thought should restrict some users to post to internet, but they can post. What is i am missing?

wingate2.JPG (68.24 KiB) Viewed 10063 times

[Aaron Koolen-Bourke]

Hi jrosen.

SSL connections do not generate WWW Proxy:: ProxyRequest events. However they generate WWW Proxy::ConnectRequest and WWW Proxy::Request events. If you attach to a WWW Proxy::Request event you can check the method to see if it's a CONNECT (Often SSL) request by adding an Expression Evaluator item with the code:

Code: Select all

Request.Method == "CONNECT";

If all you are interested in is CONNECT requests, just use the WWW Proxy::ConnectRequest event. Remember you can call policies from within a policy in order to share processing but you might be served well enough by just attaching your policy to WWW Proxy::Request instead of WWW Proxy::ProxyRequest.

I've included a few sample policies that might help. Let me know how you get on.
Aaron

[adrien]

Hi

in respect of port 443, how it goes through the proxy depends on client configuration.

If the client is configured to use a proxy for HTTPS, then it will connect to the WWW proxy, and issue a CONNECT command.

If the client is not configured to use a proxy for HTTPS, then it will probably use NAT.

If you intercepted port 443 to a WWW proxy in WinGate 6, you'd break it. In WinGate 7 if you set up a WWW proxy on port 443, and set it to use SSL for the service binding policy, and then intercept port 443, you will get certificate warnings on the client browsers, but it will make an SSL connection to the requested web server, so you can still cache and scan content.

If you set the clients to use a proxy (recommended) then the CONNECT command is also processed in the web access control rules. In policy (flow-chart) the request results in a different event than normal proxy requests. You get a ConnectRequest event instead of a ProxyRequest event. If you want one policy that can control all kinds of http requests, you can hook that policy to the Request event instead.

Hope this helps clarify.

Adrien

[adrien]

p.s.

for the method, the methods are indeed in upper case, but by default that list check will do a case insensitive check, so it should still match what you have entered there.

Are you sure the POST request is getting through that part of the policy (e.g. not being allowed somewhere else)? For instance if the request gets to the node "AuthUser Ovriga" and doesn't match, it will be allowed since there's nothing connected to the No output. Also if the client is using HTTPS to POST, that won't go through that policy.

We've done blocking based on method before, and in fact our early sample policies had a method block in them.

You may get some more helpful information if you look in the web usage logs as well, since we log by default the method. You should be able to see rejections (sc-status = 403).

Adrien

[jrosen]

Thanks Aaron And Adrien.

I think the best solutions is that the https connectionss goes through my http policy, based on what you wrote i have made the policy that you can see in the picture. In the log(http) i can see that it is working, the req is coming in and goes through my policy. However the policy(http) dont work, IE gets the "webpage could not be shown" no wingate mess in the browser when req a https page. http://abc.se work, https://abc.se gets the IE error page.
And this is what shows up in the log

Code: Select all

2011-12-02   10:28:13   122   2890   0   192.168.200.110   "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)"   192.168.200.101   CONNECT   "CONNECT abcabc.se:443"   -   403   320   1069   https   -


wingate1.PNG (6.55 KiB) Viewed 10019 times

wingate2.PNG (32.22 KiB) Viewed 10019 times

Looks that i have missed some little detail?

Regarding "post/get" thats my bad, i tried search on a swedish newspaper (http://www.svd.se/ upper right corner) but that seems not to be a post-req, i then tried an other webpage and tried to logon. That req was rejected correct. I thought the searchbox was a post req.

[jrosen]

When changing the client proxy so that SSL goes to 443 instead of 80 and also added "connect" to the get/post rule i can now surf SSL pages without the ""webpage could not be shown"". And my white/black list works.

However it seems that the SSL-traffic dont go through "web access control" and the pure sight filter.

Guess web access control works on port 80, can i add port 443 also?

[adrien]

Hi

if you're checking method, and doing HTTPS, you will only ever see CONNECT as the method. That's how HTTPS works through a proxy, by using tunnelilng.

Regards

Adrien

[jrosen]

Hi

if you're checking method, and doing HTTPS, you will only ever see CONNECT as the method. That's how HTTPS works through a proxy, by using tunnelilng.

Regards

Adrien

Ok thanks, what about getting SSL through "web access control" is that possible?

[adrien]

Hi

yes, it should go through that already. It just checks the servername that the connection is being made to.

You're running the release version?

Regards

Adrien

[jrosen]

Running 7.01 3338 (updating now to latest)

[jrosen]

I am still having problem with this, and to be honest i dont fully understand SSL and how it works in Wingate7.
Something is wrong. For example, i whitelisted https://domain1.com the restricted user gets DNS error, i then try https://domain2.com and this works but it should not when its not whitelisted..

Somehow i fucked up, is possible to get your help and you could take a look at it (teamviewer) if i started a support case?

I want to use the same whitelist and policy for http/https, and the policy is working for http.

And too clarify, what is the correct proxy settings shold the secure proxy be 80 or 443?

[adrien]

Hi

happy to have a look at your server, just open a ticket and you can send us teamviewer details etc.

as for which port to run the https proxy on.

When browsers are configured to use a proxy, they behave quite differently for https. They just use an http proxy (normally just on port 80) to request a tunneled connection through the proxy to the end server, then they negotiatate SSL over that with the server, and the proxy just relays data.

Regards

Adrien