Hi Alex, Good news. It's working now fine. I have it running on https_port and can successfully make requests using https://proxy. Just adding some comments: >> I can't trust the source network, it's on the cloud and sure it has >> other applications in the same public network. I also plan to send >> these requests through NAT from a static IP, so I can accept requests >> only from a specific IP. > > That is fine, but, FWIW, the above does not justify the need for the > allowed_target check AFAICT. It only justifies the need for authentication For sure. I like to add additional security layers. Thank you very much for your time and special attention. Cheers, Ronan On Thu, May 21, 2020 at 7:54 AM Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 5/20/20 1:38 PM, Ronan Lucio wrote: > >>> My scenario is: > >>> I have a serverless API that needs to connect to a couple specific > >>> targets from a static IP. > >>> As this serverless API doesn't have a static IP, I thought to do this > >>> through a proxy server. > >>> That's why I need to enforce security on the authentication layer. > > > >> And, I presume, you do not trust the API to only request what it should. > >> If you trust the API, then you do not need the allowed_target check. > >> > >> Also, if possible, consider using certificate-based authentication > >> rather than HTTP authentication to authenticate your clients to Squid. > >> Certificate-based authentication happens earlier, before Squid has to > >> deal with all the dangers of HTTP negotiations. > > > > I can't trust the source network, it's on the cloud and sure it has > > other applications in the same public network. I also plan to send > > these requests through NAT from a static IP, so I can accept requests > > only from a specific IP. > > That is fine, but, FWIW, the above does not justify the need for the > allowed_target check AFAICT. It only justifies the need for authentication. > > > > The idea of using Certificate-based authentication is really good. > > Is it possible to do this between client-squid or do you mean > > client-to-other-end? > > Certificate-based authentication works between any two TLS agents that > support it. Squid supports it on the https_port. > > If the client and the origin server (what you called the "other" end) > also support it, then the client can authenticate itself to both Squid > and the origin server. Please note that in this case, there will be two > (partially concurrent) TLS connections and two (sequential) > authentications going on -- Squid cannot "forward" certificate-based > authentication (and, without bumping, cannot modify the client-origin > TLS connection, including the TLS client Hello message that contains the > client certificate). > > > HTH, > > Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
