Web Access Controls for HTTPS Sites

Use this forum to post questions relating to WinGate, feature requests, technical or configuration problems

Moderator: Qbik Staff

Web Access Controls for HTTPS Sites

Postby matthius » Aug 08 22 2:44 pm

Hello All - I am still getting my head around Wingate 9.

I have it setup for home at the moment (to help keeps things under control).
I have the WWW Proxy Server setup and I can see the Web Access Control rules applying to HTTP (port 80).

On my clients (TVs, Phones, Tablets, etc) I have not set up any PROXY setting on them (which is great).

However, if I setup a test rule to block access to a site which is only over HTTPS, the access rules are not applying. As a result all users are able to access HTTPS sites with the access controls having no effect.

How do I apply the Access Control rules to both HTTP and HTTPS traffic? Do I need to setup SSL Inspection on the WWW Proxy Server and if so, is there a way that I can do this so I dont need to issue a cert to all client devices on my network as this would be exceedingly painful?
matthius
 
Posts: 5
Joined: Aug 08 22 2:36 pm

Re: Web Access Controls for HTTPS Sites

Postby adrien » Aug 09 22 1:50 pm

Hi

If the clients are not configured to use a proxy (and don't discover the proxy by proxy auto-detection mechanisms), then the way they get to go through the proxy is by intercepting the connections.

by default only port 80 is intercepted to the web proxy.

So I would expect to see the https connections showing up in the activity window as NAT: Connection to a.b.c.d:443

So there are basically 2 options. You can intercept also port 443 to the proxy, and not use SSL inspection. In this case, the proxy will snoop the servername out of the SNI field of the TLS handshake, and so should know the name of the server the client is connecting to, yet still just be tunneling data back and forth, and therefore not interfere with the security/TLS handshake. It won't see the requests, so you will only be able to block sites on a per-site basis. These requests will go through the web access control as well.

The 2nd option would be to set the clients to use a proxy. This can often be done centrally, depending on the setup you have there. Most web clients have support for some kind of proxy discovery.

If you enable SSL inspection in the web proxy, you'll need to deploy a certificate to each client, otherwise they will balk at all https connections.

there's a bit more information in the help documentation.

Regards

Adrien de Croy
adrien
Qbik Staff
 
Posts: 5437
Joined: Sep 03 03 2:54 pm
Location: Auckland

Re: Web Access Controls for HTTPS Sites

Postby matthius » Aug 10 22 8:53 pm

Thanks Adrien.

For some more context, I am doing this at home as a way of protection for family (particularly the kids). So dealing with iPads, iPhones, etc, etc. We also get their friends coming in using the wifi?

How would I go about setting up proxy discovery on my small network so I dont need to get each device and configure manually?
matthius
 
Posts: 5
Joined: Aug 08 22 2:36 pm

Re: Web Access Controls for HTTPS Sites

Postby matthius » Aug 11 22 1:38 pm

As a test, I configured a test client machine (in Firefox) to explicity use the Web Proxy. I do not perform any intercept of port 443, only port 80 in the web proxy service.

I set a test Web Access Control rule to deny any access to www.youtube.com. When I attempt to browse to that site (i.e. https://www.youtube.com) I receive an ERR_CONNECTION_CLOSED response (i.e the site can't be reached). I was expecting to see the chosen (default) BlockPage, but I dont.

Am I missing something?
matthius
 
Posts: 5
Joined: Aug 08 22 2:36 pm

Re: Web Access Controls for HTTPS Sites

Postby adrien » Aug 12 22 3:50 pm

Hi

The issue with block pages for https is that about 15 years ago, there was a security paper written where it was found that browsers could be exploited by honouring block pages from CONNECT requests, which would allow site spoofing.

Rather than fix the browsers, they decided that browsers should instead ignore any content that comes back (e.g. block page) from a proxy that the client is trying to establish a tunnel through for https. All the main browsers quickly followed suit, regardless of the protests from proxy vendors.

So now there are 2 options.

1. what you are seeing, which is the connection closed.
2. use SSL inspection, so that the proxy can fool the browser into accepting the block page.

The 2nd option comes with a few headaches, such as deployment of certificates to clients, and whitelisting certain sites from inspection (since some sites take steps to prevent this).

Regards

Adrien de Croy
adrien
Qbik Staff
 
Posts: 5437
Joined: Sep 03 03 2:54 pm
Location: Auckland


Return to WinGate

Who is online

Users browsing this forum: Bing [Bot] and 3 guests