[squid-users] ICAP and HTTPS

[Alex Rousskov]

On 10/06/2015 06:50 PM, Marcus Kool wrote:
> The 2b) option a.k.a "simply always allow the CONNECT www.example.com and
> later block GET https://www.example.com/index.html" _only_ works for
> correctly SSL-bumped sites and does not work sites that do not use
> SSL+HTTP.

If you want the user to see a non-browser error message, then _all_ of
those options require bumping, SSL, and HTTP (all three!). They only
differ in where the error message originates (Squid, ICAP, or eCAP) and
the associated development effort (if any).


> For Skype, SSH tunnels and other protocols that also use CONNECT
> the ICAP server must block the CONNECT (if configured to do so).
> There are even sites that use SSL+other protocol, so bumping such site may
> initially seem OK since the SSL handshake was done without problems,
> but since it is not followed by an HTTP protocol request, the ICAP server
> will never see a followup HTTP GET/POST and hence will never be able to
> block the site after it allowed the CONNECT.

A bumping Squid will essentially block the site in such cases though
(subject to on_unsupported_protocol controls in recent Squids).


> So if the site must be blocked, the ICAP server must already decide what
> to do when it receives a CONNECT request:
> a) guess that the CONNECT is for SSL+HTTP, pass the CONNECT and wait for
> the followup GET/POST to be blocked, or
> b) guess that the CONNECT is for a site that does not use SSL+HTTP and
> block the CONNECT.

Recent Squids also have options for detecting non-HTTP and non-SSL
traffic (see the on_unsupported_protocol directive in squid.conf).


> Because of the above, I had a discussion a long time ago with the Squid
> developers
> to extend Squid to send the (non-HTTP) content to the ICAP server in case
> that the CONNECT tunnel does not have SSL+HTTP, but the implementation
> effort was considered to be too much at that time.

What do you mean? Too much implementation effort to implement quickly?
... to implement for free? ... to implement in the next release?
Something else?

In general, improvements in Squid's non-SSL and non-HTTP content
handling should be welcomed and adaptation services may be used for that
IMO, especially when it comes to custom error generation.


Alex.