Sending CONNECT method requests over HTTPS

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Sending CONNECT method requests over HTTPS

Ronan Lucio
Hi all,

I read a similar thread a couple of weeks ago, but my scenario has
some differences.
Anyway, my need is sending CONNECT method requests over HTTPS as well.

If read the docs and just would like to confirm with you if I got it right:

1)
To send CONNECT method requests over HTTPS I'm supposed to use https_port.
May I use it on the same way as http_port (without intercept, proxy,
or accelerate)?

2)
If I need to apply ACL rules to restrict some destinations, I'm
supposed to use bump_ssl.

Is it right?

Thank you,
Ronan
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Sending CONNECT method requests over HTTPS

Matus UHLAR - fantomas
On 20.05.20 05:07, Ronan Lucio wrote:
>I read a similar thread a couple of weeks ago, but my scenario has
>some differences.
>Anyway, my need is sending CONNECT method requests over HTTPS as well.

already possible.

>If read the docs and just would like to confirm with you if I got it right:
>
>1)
>To send CONNECT method requests over HTTPS I'm supposed to use https_port.

no. It's very common to use HTTP proxy over HTTP, and the CONNECT requests
creates communication between client and server

>May I use it on the same way as http_port (without intercept, proxy,
>or accelerate)?

yes.

>2)
>If I need to apply ACL rules to restrict some destinations, I'm
>supposed to use bump_ssl.

without bumping, you can only see the destination host:port and possible
hostname sent in the SNI request and contents of the SSL certificate.

for anything else (like the https path) you must bump the connection:
decrypt the SSL tunnel, behave as the server to the client (providing it
with certificate client trusts) and behave as client to the server
(which makes e.g. SSL authentication impossible).

Note that doing this can compromise clients' security and can cause legal
issues.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Sending CONNECT method requests over HTTPS

Alex Rousskov
On 5/20/20 6:07 AM, Matus UHLAR - fantomas wrote:
> On 20.05.20 05:07, Ronan Lucio wrote:
>> I read a similar thread a couple of weeks ago, but my scenario has
>> some differences.
>> Anyway, my need is sending CONNECT method requests over HTTPS as well.

> already possible.

I assume that, here and below, "over HTTPS" means "to an HTTPS proxy".

Yes, any HTTP request, including CONNECT can be sent to an HTTPS proxy.


>> 1) To send CONNECT method requests over HTTPS I'm supposed to use
>> https_port.

> no. It's very common to use HTTP proxy over HTTP, and the CONNECT requests
> creates communication between client and server

The question is difficult to interpret correctly. Here are arguably
better questions (with answers):

Q: If I want to use an HTTPS proxy, what Squid port should I configure?
A: You must use an https_port directive.

Q: Does https_port support CONNECT requests?
A: Yes. Squid https_port supports all HTTP requests supported by
   http_port, including CONNECT.

Q: How does Squid, in an HTTPS proxy mode, handle a CONNECT request?
A: Squid handles it as it would handle a CONNECT request
   received over an http_port (by default) -- by establishing a TCP
   tunnel to the origin server and shoveling bytes back and force.
   The client-Squid portion of that tunnel would be protected by
   TLS in this case, of course -- that is always true for an HTTPS
   proxy. SslBump features are not supported in HTTPS mode (yet).


>> May I use it on the same way as http_port (without intercept, proxy,
>> or accelerate)?

> yes.

Q: Can https_port be used without an explicit mode (i.e., without
   an intercept, tproxy, accel, or ssl-bump parameter)?
A: Yes. The https_port directive supports the default (i.e. forward
   proxy) mode.

Q: What happens when https_port is used without an explicit mode?
A: Traffic on such https_port is treated as if Squid was an HTTPS proxy.


>> 2) If I need to apply ACL rules to restrict some destinations, I'm
>> supposed to use bump_ssl.
>
> without bumping, you can only see the destination host:port and possible
> hostname sent in the SNI request and contents of the SSL certificate.

Again, it is difficult to interpret this question correctly. Here are a
few versions with correct answers:

Q: Can I use ssl_bump with an HTTPS proxy?
A: No, that is not supported yet.

Q: What ACLs can I use in an HTTPS proxy mode?
A: All ACLs that do not require inspecting packets inside
   TLS connections from client to origin. Please note that
   a single client-origin TLS connection involves two
   TCP connections. That inspection is what SslBump does (among
   other things). This answer is (too) complex. Unfortunately,
   there is currently no documentation that, for every ACL,
   details precisely what information sources are required for
   that ACL to work. Some ACLs use multiple information sources,
   depending on Squid configuration and/or transaction state,
   complicating the matters further.

Q: Is TLS origin SNI available to Squid ACLs in HTTPS proxy mode?
A: No, not today. SslBump features are not yet supported in that mode.

Q: Are URL paths of HTTP requests inside CONNECT tunnels
   available to Squid ACLS in HTTPS proxy mode?
A: No, not today. SslBump features are not yet supported in that mode.


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Sending CONNECT method requests over HTTPS

Ronan Lucio
OK guys, I think you got my point.
@Alex, thank you for the well-detailed answer.

My main need is to encrypt/protect username and password (or
Proxy-Authentication header) sent on the first CONNECT to the proxy
server, in a way this username and password can't be sniffed.

The other need is creating a rule allowing only some dstdomain's.

So I understand that I can achieve that:
1. Enabling "https_port" directive (on a specific port)
2. Using an ACL rule like
    acl allowed_target dstdomain api.mydomain.com
    http_access allow auth_users allowed_target

Is that right?

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.

Thanks
Ronan

On Thu, May 21, 2020 at 1:43 AM Alex Rousskov
<[hidden email]> wrote:

>
> On 5/20/20 6:07 AM, Matus UHLAR - fantomas wrote:
> > On 20.05.20 05:07, Ronan Lucio wrote:
> >> I read a similar thread a couple of weeks ago, but my scenario has
> >> some differences.
> >> Anyway, my need is sending CONNECT method requests over HTTPS as well.
>
> > already possible.
>
> I assume that, here and below, "over HTTPS" means "to an HTTPS proxy".
>
> Yes, any HTTP request, including CONNECT can be sent to an HTTPS proxy.
>
>
> >> 1) To send CONNECT method requests over HTTPS I'm supposed to use
> >> https_port.
>
> > no. It's very common to use HTTP proxy over HTTP, and the CONNECT requests
> > creates communication between client and server
>
> The question is difficult to interpret correctly. Here are arguably
> better questions (with answers):
>
> Q: If I want to use an HTTPS proxy, what Squid port should I configure?
> A: You must use an https_port directive.
>
> Q: Does https_port support CONNECT requests?
> A: Yes. Squid https_port supports all HTTP requests supported by
>    http_port, including CONNECT.
>
> Q: How does Squid, in an HTTPS proxy mode, handle a CONNECT request?
> A: Squid handles it as it would handle a CONNECT request
>    received over an http_port (by default) -- by establishing a TCP
>    tunnel to the origin server and shoveling bytes back and force.
>    The client-Squid portion of that tunnel would be protected by
>    TLS in this case, of course -- that is always true for an HTTPS
>    proxy. SslBump features are not supported in HTTPS mode (yet).
>
>
> >> May I use it on the same way as http_port (without intercept, proxy,
> >> or accelerate)?
>
> > yes.
>
> Q: Can https_port be used without an explicit mode (i.e., without
>    an intercept, tproxy, accel, or ssl-bump parameter)?
> A: Yes. The https_port directive supports the default (i.e. forward
>    proxy) mode.
>
> Q: What happens when https_port is used without an explicit mode?
> A: Traffic on such https_port is treated as if Squid was an HTTPS proxy.
>
>
> >> 2) If I need to apply ACL rules to restrict some destinations, I'm
> >> supposed to use bump_ssl.
> >
> > without bumping, you can only see the destination host:port and possible
> > hostname sent in the SNI request and contents of the SSL certificate.
>
> Again, it is difficult to interpret this question correctly. Here are a
> few versions with correct answers:
>
> Q: Can I use ssl_bump with an HTTPS proxy?
> A: No, that is not supported yet.
>
> Q: What ACLs can I use in an HTTPS proxy mode?
> A: All ACLs that do not require inspecting packets inside
>    TLS connections from client to origin. Please note that
>    a single client-origin TLS connection involves two
>    TCP connections. That inspection is what SslBump does (among
>    other things). This answer is (too) complex. Unfortunately,
>    there is currently no documentation that, for every ACL,
>    details precisely what information sources are required for
>    that ACL to work. Some ACLs use multiple information sources,
>    depending on Squid configuration and/or transaction state,
>    complicating the matters further.
>
> Q: Is TLS origin SNI available to Squid ACLs in HTTPS proxy mode?
> A: No, not today. SslBump features are not yet supported in that mode.
>
> Q: Are URL paths of HTTP requests inside CONNECT tunnels
>    available to Squid ACLS in HTTPS proxy mode?
> A: No, not today. SslBump features are not yet supported in that mode.
>
>
> HTH,
>
> Alex.
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Sending CONNECT method requests over HTTPS

Alex Rousskov
On 5/20/20 1:00 PM, Ronan Lucio wrote:

> My main need is to encrypt/protect username and password (or
> Proxy-Authentication header) sent on the first CONNECT to the proxy
> server, in a way this username and password can't be sniffed.
>
> The other need is creating a rule allowing only some dstdomain's.
>
> So I understand that I can achieve that:
> 1. Enabling "https_port" directive (on a specific port)
> 2. Using an ACL rule like
>     acl allowed_target dstdomain api.mydomain.com
>     http_access allow auth_users allowed_target
>
> Is that right?

Your plan looks OK to me if the client is going to send domain names in
its CONNECT requests. Many clients use IP addresses instead. The
dstdomain ACL will attempt to do a reverse DNS lookup for an IP address,
but that is often not reliable.


> 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.

Alex.


> On Thu, May 21, 2020 at 1:43 AM Alex Rousskov wrote:
>>
>> On 5/20/20 6:07 AM, Matus UHLAR - fantomas wrote:
>>> On 20.05.20 05:07, Ronan Lucio wrote:
>>>> I read a similar thread a couple of weeks ago, but my scenario has
>>>> some differences.
>>>> Anyway, my need is sending CONNECT method requests over HTTPS as well.
>>
>>> already possible.
>>
>> I assume that, here and below, "over HTTPS" means "to an HTTPS proxy".
>>
>> Yes, any HTTP request, including CONNECT can be sent to an HTTPS proxy.
>>
>>
>>>> 1) To send CONNECT method requests over HTTPS I'm supposed to use
>>>> https_port.
>>
>>> no. It's very common to use HTTP proxy over HTTP, and the CONNECT requests
>>> creates communication between client and server
>>
>> The question is difficult to interpret correctly. Here are arguably
>> better questions (with answers):
>>
>> Q: If I want to use an HTTPS proxy, what Squid port should I configure?
>> A: You must use an https_port directive.
>>
>> Q: Does https_port support CONNECT requests?
>> A: Yes. Squid https_port supports all HTTP requests supported by
>>    http_port, including CONNECT.
>>
>> Q: How does Squid, in an HTTPS proxy mode, handle a CONNECT request?
>> A: Squid handles it as it would handle a CONNECT request
>>    received over an http_port (by default) -- by establishing a TCP
>>    tunnel to the origin server and shoveling bytes back and force.
>>    The client-Squid portion of that tunnel would be protected by
>>    TLS in this case, of course -- that is always true for an HTTPS
>>    proxy. SslBump features are not supported in HTTPS mode (yet).
>>
>>
>>>> May I use it on the same way as http_port (without intercept, proxy,
>>>> or accelerate)?
>>
>>> yes.
>>
>> Q: Can https_port be used without an explicit mode (i.e., without
>>    an intercept, tproxy, accel, or ssl-bump parameter)?
>> A: Yes. The https_port directive supports the default (i.e. forward
>>    proxy) mode.
>>
>> Q: What happens when https_port is used without an explicit mode?
>> A: Traffic on such https_port is treated as if Squid was an HTTPS proxy.
>>
>>
>>>> 2) If I need to apply ACL rules to restrict some destinations, I'm
>>>> supposed to use bump_ssl.
>>>
>>> without bumping, you can only see the destination host:port and possible
>>> hostname sent in the SNI request and contents of the SSL certificate.
>>
>> Again, it is difficult to interpret this question correctly. Here are a
>> few versions with correct answers:
>>
>> Q: Can I use ssl_bump with an HTTPS proxy?
>> A: No, that is not supported yet.
>>
>> Q: What ACLs can I use in an HTTPS proxy mode?
>> A: All ACLs that do not require inspecting packets inside
>>    TLS connections from client to origin. Please note that
>>    a single client-origin TLS connection involves two
>>    TCP connections. That inspection is what SslBump does (among
>>    other things). This answer is (too) complex. Unfortunately,
>>    there is currently no documentation that, for every ACL,
>>    details precisely what information sources are required for
>>    that ACL to work. Some ACLs use multiple information sources,
>>    depending on Squid configuration and/or transaction state,
>>    complicating the matters further.
>>
>> Q: Is TLS origin SNI available to Squid ACLs in HTTPS proxy mode?
>> A: No, not today. SslBump features are not yet supported in that mode.
>>
>> Q: Are URL paths of HTTP requests inside CONNECT tunnels
>>    available to Squid ACLS in HTTPS proxy mode?
>> A: No, not today. SslBump features are not yet supported in that mode.
>>
>>
>> HTH,
>>
>> Alex.
>>
>> _______________________________________________
>> squid-users mailing list
>> [hidden email]
>> http://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Sending CONNECT method requests over HTTPS

Ronan Lucio
Hi Alex,

> > 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.

That's a good point.
First, I can trust the requester API, but 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.

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?

Thanks
Ronan
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Sending CONNECT method requests over HTTPS

Alex Rousskov
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Sending CONNECT method requests over HTTPS

Ronan Lucio
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
<[hidden email]> 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users