I have been testing the webshield site blocking feature. While this does block HTTP URLs it does not appear to block HTTPS no matter what format or wildcard settings I put in the site blocking page. Note: I am changing this in a template on the portal although doing a change in the client also makes no difference.
I also note that on the portal under Settings template Windows Server Web Shield I have an enable tick box for HTTPS scanning but no such tick box exists on the client.
Is the HTTPS scanning feature still to be implemented in the client or is this just a bug that is known and will be fixed at a later date?
If there is a way to block HTTPS URLs can you enlighten me as to how.
When excluding a sit try adding the exclusion in this format facebook it should then block anything with “facebook” in the name. There are issues with twitter that we are aware of that it doesn’t block the entire site but renders it usless for the most part.
Let me know if you have further questions or issues.
As I explained in my original post I have tried all combinations of wildcard formats and none stop HTTPS site access. The same wildcard formats do stop HTTP sites so this is an issue with HTTPS connections, hence my query whether this feature has been implemented in the client yet.
What browser are you using? Make sure when you add the exception in the portal it’s populating on the local client(s).
There is an issue with HTTPS sites but as shown in the screen shot attached, I have had success with the sitename format.
Is there a specific site that you are trying to block that’s not working?
For facebook, I tested this in Chrome, firefox and IE and all 3 blocked facebook.
If you can let me know some specifics as far as browser, version and site(s) you are having issues with, we will take a look and see if we can come up with something that will work for you.
Thanks for your reply… Having been away for a few weeks I looked at this issue again to get the information you asked for. Having started my test system, which had been off while I was away, and having made no changes to the portal or client settings, I tried accessing some of the sites in my block list and to my surprise it was now blocking the https sites.
I don’t know whether it was a reboot or some other change / client update but the client is now blocking the https sites listed.
For your information I was testing with IE9+ and firefox 38 and 39. I always made sure the client had been updated with any changes I made on the portal prior to testing the blocking.
I can confirm Peter313’s observation about entries in the portal without http or https are being sent to the client or being interpreted by the client as http:// however this is not the cause of my issue as I have specifically added https:// entries for testing.
I will continue my testing with adding more sites to block to see if I can identify what actions may be needed (i.e. a reboot) before https entries in the portal are blocked by the client.
This has highlighted one issue that the portal or client defaults any entry without http or https as http only rather than what I would expect to happen that not specifying http or https should cause both to be blocked. Perhaps that is something you can pass back to the developers for comment / action.
I have confirmed that my failure to block HTTPS sites is related to Windows Server 2003 as it always gets blocked on Windows Server 2012. Both systems are using the same template so its not a config error.
Windows Server