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