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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
