The problem
Using Google search will often take users (unknowingly) to the HTTPS version of their search engine. This changes the search experience as the data and content become encrypted, making it hard to filter against content or key words using filter systems such as WebScreen 2 and prevents the Google Safe Search function from being enforced.
The solution
If you wish to disable Google searches from taking place in an HTTPS environment so that filtering rules can be enforced along with Safe Search, you can do so by using the DNS servers in the core of the LGfL Network. These have been configured to ensure that any request for https://www.google.ee is redirected to a non-HTTPS version of the Google site in the locale requested. This means that for example if a user trys to surf to https://www.google.ee/ they will always end up at http://www.google.ee/
This DNS redirection does NOT affect other Google systems such as Gmail, to which secure access is still available.
In the LGfL 2.0 network, the LGfL core DNS servers located at 172.30.178.53 and 172.30.178.54 can be used to perform this redirect for Google, in other broadband networks use your core DNS servers.
If you do not wish to make use of this service and wish to run your own local DNS then you can point them at root DNS servers on the internet which are NOT blocked on your network by default.
If you wish to completely secure your school’s network then please raise a support case and ask for all non-core DNS requests to be blocked through your local firewall. This will prevent local users from changing the DNS servers they are using away from the core servers.
In an environment containing machines running Windows XP, users may have had difficulties accessing LondonMail when using certain browsers. This issue is related to the blog post below regarding access to secure sites using Windows XP.
In order to grant access to LGfL-supported Microsoft services such as LondonMail, the relevant WebScreen 2.0 filtering policies need to have the Microsoft IP ranges added to the Allowed URL and keyword lists in those policies.
It is important to note that if you have previously allowed the category “Host is an IP” in your policies to overcome problems with accessing LondonMail, then you may wish to consider blocking this category once more to ensure maximum control of access to sites which may be accessed via IP addresses rather than more conventional URLs.
For full details and a list of the required IP ranges please see the WebScreen 2.0 FAQs section found in the Support Site User Guide.
Due to the way Microsoft XP interacts with various browsers, users of Internet Explorer, Chrome or Safari browsers on a workstation running Windows XP, are likely to experience an issue when trying to access https sites. Only this particular combination of technologies is affected due to the way Microsoft handles https sites in XP. Please note that Firefox users will NOT be affected in the same way as Firefox bypasses the built-in Microsoft XP routines. There are also no issues with any of the browsers in combination with a later version of Windows. The best long-term solution is to upgrade workstations to a later version of the operating system or use Firefox as the default browser.
Under XP, when browser requests to https sites are sent using the full standard URL, the URL gets translated to the IP address of that site before it reaches the filtering system. Access to the site may then be denied unless the IP address has been explicitly allowed.
For example: a request to visit
https://www.google.com/
is presented to the filtering system as a request for
https://173.194.67.105/
Further complications may arise when destination sites have multiple IP address possibilities as they are hosted on multiple servers. So the above example could appear as
https://173.194.78.104/
depending upon the address to which the URL translates at the time.
As a result, to ensure that an https site is allowed/blocked correctly for those using the XP system with one of the affected browsers, the URL and any IP addresses belonging to the site should be added to the appropriate filtering policy. This approach is effective in situations where target websites are hosted on single IP addresses that can be identified relatively easily, either by pinging the target URL and making note of the IP address returned or by a careful examination of the reports available under the Webscreen 2.0 interface on the USO support site.
It should be noted that although the category “Host is an IP” can be allowed, this results in any https site becoming accessible.
Major changes to the way the Youtube safesearch facility operates (implemented by its owner Google) have meant that, for the last few months, it has not been possible to enforce Youtube safesearch through filtering policies configured in WebScreen 2.0. Safesearch could be configured within the Youtube site but this would have to be done on an individual basis for all users.
However, we are pleased to announce that, as of 8 March 2012, work carried out by Atomwide and its technology partners once again makes it possible to enforce safesearch within the youtube.com site by switching on the safesearch functionality within the relevant filtering policy.