[squid-users] squid4.4 - ssl_bump - deny_info / how to present a blocked message for unwanted https traffic

[Amos Jeffries]

On 5/12/18 8:10 pm, Andreas Moehrlein wrote:
> I use squid as a proxy to enable some http and https sites and redirect all other traffic to a captive portal.
> Everything works fine, except for a redirect/deny_info for the not allowed https traffic.
> 
> Is there a mechanism, I can use to show a error message for https ?
> 

The TL;DR short answer:

  No, sorry, it is effectively impossible.


The longer version:

Browsers refuse to display any messages provided by proxies in response
to a CONNECT attempt. They replace them with their own in-house
messages. Usually blaming the proxy for 'connection failure', regardless
of what actually happened.

The only way around that is for the proxy to MITM and decrypt the TLS
traffic and forge an HTTP error response to the first HTTP request it
finds in there.

Which in the scenario of a Captive Portal effectively means that it is
impossible until Browsers change their behaviour. The Browser does not
have prior setup to trust the proxy CA in order for the handshake to
complete and error message to be delivered.

If you have any ability to configure the browser for that trust, then by
definition it is not a Captive Portal situation. Use it as a regular TLS
Proxy instead and your error and/or redirection should work _relatively_
okay, most of the time, sort of.



> All http + https traffic is redirected to squid via iptables.
> Deny_info works perfect for http.
> 
> /etc/squid/squid.conf
> 
> acl step1 at_step SslBump1
> acl https_whitelist ssl::server_name "/etc/squid/acl/general.list"
> 
> ssl_bump peek step1 all
> ssl_bump splice https_whitelist
> ssl_bump terminate all
> 
> deny_info http://10.10.12.1:81/captureme?redirect=%u all
> 

Please be aware that deny_info is the parameters on how to generate an
*HTTP* protocol response message when a "deny" action is initiated for
an HTTP transaction. The above line connects your parameters to the ACL
named "all" so denial by HTTP access control lines ending with " all"
(eg "http_access deny all") will send a redirect to that URL.

ssl_bump terminate is different in several important ways:

 * Firstly it is not access control for an HTTP transaction - it
flow-controls the stages of a TLS protocol handshake. Thus no "error
message" exists in the sense you are looking for.

* Secondly it uses a "terminate" action not a "deny". The entire
semantics and binary-layer of what is going on are critically different.
  The "terminate" takes the form of a TLS Alert frame of slightly more
than 4 bytes, usually followed with or embedded in a TCP FIN packet. No
HTTP at all and certainly nothing even resembling redirect possible (so
we cannot even map your intention into the TLS format).


Overall with this setup no there is no chance at all of the proxy error
message even existing let alone being sent to any User.


Amos