This tutorial is based on the excellent article The Ars guide to building a Linux router from scratch available at https://arstechnica.com/gadgets/2016/04/the-ars-guide-to-building-a-linux-router-from-scratch. Please consider this tutorial only as a proof-of-concept. Consult your network administrator before putting it into real production.
From now on we will assume you already gone through all the steps of the Ars guide to build your own router on Ubuntu 16. You would like to add web filtering of HTTP and HTTPS traffic to the mix. This will be implemented by by using Squid proxy for transparent interception of traffic and Web Safety ICAP server for actual web filtering.
Read more at https://docs.diladele.com/tutorials/transparent_proxy_ubuntu/index.html
UPDATED: June, 13, 2017 – another build of 5.1. The bypass by token now works correctly. FreeBSD 10 based build also functional. Added intermediate certificate storage management.
There is a new 5.1 build available at https://www.diladele.com/download_next_version.html. This version contains the ability to bypass the blocked page (eventually using a bypass token but this does not work for now).
Upon being presented with a blocked page user can click on “Proceed Anyway” button and the domain is then added to a temporary white-list. Bypass time and allowed policy to do the bypass can be customized.
Internally we have changed a lot in the Admin UI, splitting the complex Django code files into small and manageable classes. Hopefully we did not lost anything during the transition but you can never know for sure. Please if you find any bug or issue – do report at https://github.com/diladele/websafety-issues/milestones
We are now trying to make bypass by token work and fixing FreeBSD build.
Diladele Dev Team.
After Chrome 58+ started to check for presence of subjAltName extension in SSL certificates presented by the remote sites, it turned out that the order of sslbump directives that Admin UI generates is not completely incorrect. If you have blocked http://www.youtube.com in Web Safety, then accessing https://www.youtube.com in Chrome 58+ results into ERR_CERT_COMMON_NAME_INVALID error message instead of the expected access forbidden page.
Consider the following.
* We have blocked access to .youtube.com in Default Policy / Block by Domain.
* User types https://www.youtube.com into address bar of the browser. Note the httpS:// schema!
* Browser tries to establish CONNECT tunnel to http://www.youtube.com through Squid proxy.
* Squid forwards this request to ICAP web filter.
* Web Safety instructs Squid to decrypt the HTTPS connection (to be able to show the blocked page later).
* Squid mimicks the SSL certificate of http://www.youtube.com without contacting the actual YouTube. Thus mimicked certificate does not have subjAltName extension included.
* Chrome 58+ shows “Your connection is not private” message.
This happens because by default Squid does not include subjAltName extension into SSL certificates generated without contacting origin servers. See bug http://bugs.squid-cache.org/show_bug.cgi?id=4711 (will be fixed in Squid version 3.5.25+).
To fix this issue we need to reorder the SSL bump directives that Web Safety generates. Continue reading at https://docs.diladele.com/faq/squid/chrome_ssl_filter/wrong_order_of_peek_and_splice.html