[squid-users] Sending CONNECT method requests over HTTPS

Ronan Lucio ronanlucio at gmail.com
Wed May 20 23:39:25 UTC 2020


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 at measurement-factory.com> 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.


More information about the squid-users mailing list