Restricting WWWProxy Access

[pAnoNymous]

I'm trying to restrict access to a certain urls/resources. E.g. https://www.hsbc.co.uk/1/themes/html/hs ... default.js

The polices I've been testing work fine with http://www.hsbc.co.uk/1/themes/html/hsb ... default.js but fail with https equivalent. Is this possible?

[adrien]

https is quite a different mechanism to http.

in fact the first thing the browser does is negotiate a secure connection (that WinGate can't see) before it makes the request.

So WinGate doesn't see the URL for https. Only the servername.

Regards

Adrien

[Alen]

adrien, is the issue somehow solved or walked around in Wingate 7?

[logan]

This isn't an issue that has a solution or work around. The sole purpose of HTTPS is to prevent middle men (anything between the client and the intended server) from snooping inside the secured HTTP packets. If it was easy to snoop inside HTTPS packets without setting off alarm bells on the client computer, then HTTPS wouldn't be of much use any more :).

As HTTPS secures online communications such as internet banking, credit card payments and personally identifiable information, it really doesn't pay to entertain the thought of messing around with HTTPS packets in the first place.

[Alen]

I understand that, there is no need to look inside data (which has to be impossible), just block sites by urls and their parts.

[logan]

You can still block HTTPS access by the server name (e.g. http://www.server.com), but the path (everything after the server name) is encrypted and we can't do anything with that. I should also mention that you can only do this if the client is manually configured to use the proxy server. If the client thinks it's connecting directly to the destination server (i.e. WinGate is intercepting the connection), the client will encrypt the server name as well and WinGate is left well in the dark.

By setting the HTTPS proxy, the client leaves just enough information unencrypted for the proxy to handle the request, but no more than what's necessary.

[adrien]

Hi all (and Logan!)

Just to clarify, the reason WinGate even may see the server name is if the client is configured to use a proxy for HTTPS, it will use the proxy to open a tunneled TCP connection to the server by sending an HTTP CONNECT command. This CONNECT command contains the servername and port.

After this connection goes through, the client negotiates a SSL/TLS layer, and after that sends the HTTP request over that connection. This is the bit we can't see. That's why we can only block based on servername / port.

There are some more devices coming out nowadays that advertise support for inspecting this https traffic. The way they do that is by mounting what's known as a man-in-the-middle attack.

They intercept the connection of the browser, make an SSL connection to the server that the browser was trying to connect to. Get the certificate from the server. Make a new fake certificate with the same details scraped out of the real server certificate, then use that fake cert to negotiate SSL with the client. Since the name in the cert is the same, the browser doesn't complain about that, although often the browser will complain that the site certificate isn't signed by a trusted root. This is typically worked around by installing a certificate on all LAN computers that is used to sign the fake certificates in the proxy.

Some security people say it's a terrible thing to break the security of SSL like that.

Other people say they need to scan that traffic, since more and more malware uses SSL.

WinGate 7's HTTP proxy has the capability to intercept on port 443 to a binding using SSL, and it then makes a SSL connection to the server. At the moment we don't spoof certificates although this is on the cards. What that means is if you decide to intercept port 443 in WinGate 7 to a WWW proxy using SSL on its bindings, then it will work but give certificate nag warnings to the users (most users just click ok anyway).

[Alen]

WinGate 7's HTTP proxy has the capability to intercept on port 443 to a binding using SSL, and it then makes a SSL connection to the server. At the moment we don't spoof certificates although this is on the cards. What that means is if you decide to intercept port 443 in WinGate 7 to a WWW proxy using SSL on its bindings, then it will work but give certificate nag warnings to the users (most users just click ok anyway).

Thank you for the information. Do you expect or meet that some applications could fail to work properly in the case of such a double SSL connections?

You can still block HTTPS access by the server name (e.g. http://www.server.com), but the path (everything after the server name) is encrypted and we can't do anything with that. I should also mention that you can only do this if the client is manually configured to use the proxy server.

Several month ago I had an issue with www.toto.am website. Wait, need to remember and check.
...
I just checked, it was not Wingate issue, but PureSight. I had gambling denied in PS, but was asked by the chief to allow the site for 10 minutes. After enabling the restriction again I found that users are still able to connect to the site by https.

I realise now, the problem is PS is not checking sites accessed by https at all! Very sad and wrong. Can you influence somehow on the developer?


P.S. Just checked, indeed Wingate is able to block the website by url contents. Very good.