[squid-users] url_rewrite_program, sslbump and CONNECT = broken redirect page?

[Amos Jeffries]

On 19/03/19 10:45 pm, Amish wrote:
> Hello,
> 
> I have perfectly working SSL bump setup (via proxy CONNECT requests)
> except when a site is blocked.
> 
> I have a rewrite program which blocks say foo.com.
> 

Please remember there is a difference between "rewrite" (what you are
actually doing) and "redirect" (per your subject).

* Redirect is a standardized HTTP mechanism. It works wherever the
client support that basic HTTP mechanism.

* Rewrite is an abuse of the proxy place in the protocol. It more often
causes problems than works.


> Roughly it does this:
> 
> HTTP - non secure
> STDIN: GET http://foo.com
> STDOUT: rewrite-url="http://127.0.0.1/blocked"
> 
> Above works fine as expected, the page is fetched and shown.
> 
> But now if it is a CONNECT (https) request:
> 
> STDIN: CONNECT foo.com:443
> STDOUT: rewrite-url="http://127.0.0.1/blocked"
> 
> Then instead of fetching the above page it tries to fetch "CONNECT
> http:443" and returns ERR_DNS_FAIL page.
> 
> The problem code begins here: (client_side_request.cc)
> https://github.com/squid-cache/squid/blob/master/src/client_side_request.cc#L1261
> 

No. The problem starts with the helper ignoring the method and original
URI form/structure Squid passed to it.


> 
> which leads to: (AnyP:;Uri parse() function)
> https://github.com/squid-cache/squid/blob/master/src/anyp/Uri.cc#L211
> 
> which treats CONNECT request differently then what is documented.
> 

The authoritative documentation is the code comment starting at that
files #L212, and the RFC it references. Other documentation which does
not align is outdated and/or incorrect.


Specifically be aware that URI and URL are different things. Your helper
is responsible for delivering whichever URI syntax is valid as
request-target for the message being re-written. Squid passes the method
name to the helper for exactly this case.


> It finds domain as something colon number. And looks like ignores
> urlpath completely.

authority-form URI have no such thing as a path. They are a hostname (or
raw-IP) a colon, and a port number. Any remainder is garbage.


> 
> So in my case it becomes http:443.
> 
> And hence redirection breaks.

Redirection would not work regardless of what Squid does with your
helpers output. The client is sending native TLS on the connection - the
redirected-to URL is HTML or something like it.

At best you can hope for is the client to spontaneously abort with a TCP
RST.

At worst the client can enter an infinite series of attempts to
re-connect ... until your proxy machine consumes all available TCP ports
and *all* TCP traffic through the machine halts - even traffic by other
software or the OS itself.


> 
> How do I convert CONNECT requests over ssl bump to GET
> http://127.0.0.1/blocked
> 

You cannot deliver protocol X to a client which is expecting
incompatible protocol Y and have anything good happen.

In this case probably delivering HTML text (or similar) to a client
expecting a TLS serverHello message.


> This exact issue was reported earlier too in 2015 but the person who
> reported it probably couldn't locate the exact reason and bug went
> unnoticed.

It was not unnoticed. Has been reported many times over the years. The
bug is in the helper.


You should fix the helper (if possible) to cope with CONNECT and other
unusual types of URI input it may receive. There may be protocols other
than "http://", path-only URLs, URN, or even just an asterisk ('*') on
some methods.
 <https://tools.ietf.org/html/rfc7230#section-5.3>
 <https://tools.ietf.org/html/rfc3986>

To re-write the helper output must not only be a valid URI, but also
compatible with the operations the original URI was going to perform.


If that is not possible, you can workaround this particular case by
adding this to your squid.conf to skip processing of the CONNECT
messages entirely:

 url_rewrite_access deny CONNECT


Cheers,
Amos