[squid-users] Squid and url modifying

[Amos Jeffries]

On 2/03/19 1:59 am, Egoitz Aurrekoetxea wrote:
> Good afternoon,
> 
> 
> Is it possible for Squid to do something like :
> 
> 
> - Receive request : https://oooeeee.eeee.ttt.thesquidserver.org/u?ii=99&j=88
> 
> 
> and
> 
> 
> to really perform a request as : https://oooeeee.eeee.ttt/u?ii=99&j=88
> <https://oooeeee.eeee.ttt.thesquidserver.org/u?ii=99&j=88>
> 

Possible? Yes.

Good Idea? No.

This is a typical URL-rewrite. Except that in order to perform the
SSL-Bump to see that URL in the first place Squid has probably had to
contact the server and now has TLS bound to that particular server. So
you better hope the server oooeeee.eeee.ttt.thesquidserver.org knows how
to answer requests for the https://oooeeee.eeee.ttt/* URLs.

Avoiding that problem is only possible with bumping at step2 (aka.
client-first bumping). Which opens your proxy to a large number of
possible attacks and nasty side effects from incompatible TLS features
being negotiated on client and server connections.
 YMMV on whether that is even usable for your situation.


> 
> I mean not to redirect users with url redirection. Just act as a proxy
> but having Squid the proper acknoledge internally for being able to make
> the proper request to the destination?. Is it possible without
> redirecting url, to return for instance a 403 error to the source web
> browser in order to not be able to access to the site if some kind of
> circumstances are given?

Of course.

The issue people tend to have is that Browsers do not show proxy error
messages in a lot of circumstances. They still show *an* error though.
So if your goal is just to block, yes that much is relatively easy.


> 
> If all conditions for allowing to see the content are OK, return the web
> browser a 301 redirect answer with the
> https://oooeeee.eeee.ttt/u?ii=99&j=88
> <https://oooeeee.eeee.ttt.thesquidserver.org/u?ii=99&j=88> URL. Else,
> just return a 403 or redirect you to a Forbidden page... I think this
> could be implemented with URL redirectors...but... the fact is... which
> kind of conditions or env situations can you use for validating the
> content inside the url redirector?.

302 is better since this is not a permanent state. Your policy may
change any time.

Anyhow, 30x redirection is the *best* way to do it.

The helper is contacted by Squid after the TLS has been decrypted and
the HTTP(S) messages area arriving. Before that point there is no URL to
rewrite or redirect.

Helpers can do anything they like. Squid can pass them details of the
client TCP connection, the TLS state, or the HTTP request the client has
delivered. And some other details (eg rDNS, IDENT, ASN or such) that
Squid can lookup. Anything else the helper can lookup by itself can also
be used.

That extreme flexibility is the point of the helper. If you just need a
somewhat static mapping deny_info can perform redirection faster.


Amos