Older Version of Web Safety < 5.1 - incorrect order of SSL bump directives

Important

This article is now obsolete. Latest version of Web Safety handles HTTPS decryption for Google Chrome without any errors.

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 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.

../../../_images/youtube_blocked_cn_invalid.png

Consider the following.

  1. We have blocked access to .youtube.com in Default Policy / Block by Domain.

  2. User types https://www.youtube.com into address bar of the browser. Note the httpS:// schema!

  3. Browser tries to establish CONNECT tunnel to www.youtube.com through Squid proxy.

  4. Squid forwards this request to ICAP web filter.

  5. Web Safety instructs Squid to decrypt the HTTPS connection (to be able to show the blocked page later).

  6. Squid mimicks the SSL certificate of www.youtube.com without contacting the actual YouTube. Thus mimicked certificate does not have subjAltName extension included.

  7. 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. Login into console of Web Safety box as root and open the following files:

  • for 4.8 and 4.9 - /opt/qlproxy/var/console/squid/templates/squid/conf/ssl.conf

  • for 5.0 - /opt/websafety/var/console/squid/templates/squid/conf/ssl.conf

  • for 5.1+ - it is fixed already so nothing needs to be done.

Approximately at line 300, change (reorder) the lines so that peek directive comes before bump directive. This will let Squid first look into the actual server certificate and only then mimick the certificate.

WAS:

# force bump in both all and targeted mode
ssl_bump bump ssl_force_bump

# peek at SNI the client sent to us
ssl_bump peek step1 all

NOW MUST BE:

# peek at SNI the client sent to us
ssl_bump peek step1 all

# force bump in both all and targeted mode
ssl_bump bump ssl_force_bump

Click Save and Restart from Admin UI and after refresh in your browser the expected “blocked page” will be shown.

../../../_images/youtube_blocked_cn_valid.png