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