Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Control » web filter https
  •  
fchiaravalli@tecniplast.i

Messages: 4
Karma: 0
Send a private message to this user
I'm testing keriowinroutefirewall 6 with webfilter and I'm surprise to see that it doesn't filter "https" connection, all the deny categories "Porno, Chat, etc. etc." are working well with the http protocol but it doesn't work if the webpage is under "https", so all the chat, webmail, social networking are working, and I cannot control the surf navigation as I want, I hope that this is a bug and there will be a solution to resolve this.
Best Regards Fabrizio
  •  
winkelman

Messages: 2119
Karma: 3
Send a private message to this user
HTTPS traffic is encrypted between the client and the webserver. So the firewall (which sits in between) can't see anything in the HTTP stream. It's impossible for Kerio to even determine the URL, the only thing Kerio knows it's routing encrypted bits between a local IP and public IP address.

I agree with you it's a problem, it means that as firewall admins we are pushed into an impossible corner:

  • block all HTTPS traffic for users (which is totally unpractical)
  • manually block Internet IP addresses which are porn/chat/etc. (also impossible)
  • or allow all HTTPS traffic (which is unwanted).

There's just not much that can be done about it. (Until the ISS Orangeweb filter is also able to categories based on remote IP addresses instead of URL's.)

[Updated on: Fri, 19 June 2009 09:54]

  •  
slash

Messages: 14
Karma: 0
Send a private message to this user
Hello Winkelmann

you wrote:

### HTTPS traffic is encrypted between the client and the webserver. So the firewall (which sits in between) can't see anything in the HTTP stream. It's impossible for Kerio to even determine the URL, the only thing Kerio knows it's routing encrypted bits between a local IP and public IP address. ###

That's true, but the Client is using either the Winroute Proxy or the Winroute Firewall to access the Internet and in this Case, Winroute does know about the destination IP and the destination URL. In this case, it is/should be possible to verify the URL (which is not encrypted) within https packets against the Cobion Filter List.

Try to blacklist or whitelist a https website by using the syntax: <http://url:443>

greetings from /
  •  
winkelman

Messages: 2119
Karma: 3
Send a private message to this user
slash wrote on Tue, 23 June 2009 14:16

Winroute does know about the destination IP and the destination URL. In this case, it is/should be possible to verify the URL (which is not encrypted) within https packets against the Cobion Filter List.

Are you sure? I've always thought that even the URL's are encrypted within the https-stream. The only thing not encrypted is the destination address of the webserver.

Thus Kerio could filter on destination address, but not on destination URL...
  •  
slash

Messages: 14
Karma: 0
Send a private message to this user
Hello winkelmann ......sorry for responding late

you wrote:

Are you sure? I've always thought that even the URL's are encrypted within the https-stream. The only thing not encrypted is the destination address of the webserver.

Thus Kerio could filter on destination address, but not on destination URL...


If the clients webbrowser is using the DNS server of the Routing System or the Winroute DNS or is using Winroutes Proxy, I think winroute has to know about the URL the client is requesting.
Because in this case, Winroute has to translate the https://www.google.com into an IP Address and in this second, this URL can be requested into the URL Filter.
As far as I know, the URL of the http Packet can not be encrypted, only the HTML Body. If everything is encrypted, no DNS or no Proxy between client and server is able to route or fetch (Proxy) the requested packets. And thats the point, a webfilter can investigate.
does it make sense?

//slash
  •  
winkelman

Messages: 2119
Karma: 3
Send a private message to this user
Quote:
think winroute has to know about the URL the client is requesting.
Because in this case, Winroute has to translate the https://www.google.com into an IP Address and in this second, this URL can be requested into the URL Filter.

does it make sense?


Not fully...

Another example illustrates this. Say a user wants to visit:

https://www.kerio.com/firewall/user-management/web-content-filter

The request to the DNS server only contains a request what IP address is host www.kerio.com, it doesn't contain the full URL. Once the clients knows the IP address of the webserver at www.kerio.com, the HTTPS stream to it, including the full URL, is encrypted, so not filterable by the filters of KWF.

The initial DNS request is indeed unencrypted, and that's why you can still block traffic to a complete HTTPS site with a Traffic Policy. But since the actual URL's are encrypted, you can't block traffic to 'within' HTTPS sites using URL Filters.

So you could block all HTTPS traffic to www.kerio.com, but not filter based on the different pages on www.kerio.com.

This is how I understand it.
Previous Topic: Log in Proglem in KW Firewall 6.4.2
Next Topic: Rule Max Ip - Port
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Mon Nov 20 20:15:20 CET 2017

Total time taken to generate the page: 0.00428 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.