[squid-users] Squid marking QOS and matching marks with linux iptables problem !
Hello Folks , Im trying to mark outgoing squid request based on Mark linux matching . I added to squid conf : qos_flows mark local-hit=0xd7 qos_flows mark local-miss=0xd7 -A OUTPUT -m mark --mark 0xd7 -j ACCEPT But on iptables there is no match with the mark 0xd7 Im testing marking with squid and matching with iptables but its not matching , always statistics = 0 on linux iptables That mean its not matched . Squid version is 4.8 Also squid was complied with '--enable-zph-qos’ flag So not sure if I need specific config for squid . Following : https://wiki.squid-cache.org/Features/QualityOfService Based on it we need kernel patch for TOS , but I dont need TOS , I just need Layer 3 DSP , Linux mark rule based . i even tried to match traffic by mark and connmark and both did not help . -A OUTPUT -m mark --mark 0xd7 -j ACCEPT -A OUTPUT -m connmark --mark 0xd4 -j ACCEPT So both rules above was not able to pickup squid marking . Any helping Team on this case ? Thank you ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Sending CONNECT method requests over HTTPS
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 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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Sending CONNECT method requests over HTTPS
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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Sending CONNECT method requests over HTTPS
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Sending CONNECT method requests over HTTPS
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.
Re: [squid-users] Sending CONNECT method requests over HTTPS
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 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@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid 3.5 reverse proxy https configuration problem
On 5/20/20 12:20 PM, sjmeyer wrote: > I have a squid configured as a reverse proxy on RHEL 7.8 > > the certificates on the squid box seem okay the squid -k parse passes, > however when I attempt to access the back-end server via squid I get > > Error negotiating SSL connection on FD 13: error:14094416:SSL > routines:ssl3_read_bytes:sslv3 alert certificate unknown (1/0) AFAICT, your client (e.g., a browser) probably does not trust Squid's certificate (i.e., /etc/squid/tls/devi_public.pem). Should it? What does the client say? > It'd my understanding to resolve the SSL error I need to add the CA of the > backend sever to the RHEL trust store If my understanding about the scope of the error is correct, then the backend server is irrelevant. The error is between the TLS/HTTPS client and Squid, not Squid and cache_peer. Squid has not yet contacted the cache_peer at the time of this error. HTH, Alex. > - I have done that, copied the ca to > /etc/pki/ca-trust/source/anchors/ > ran update-ca-trust extract, > confirmed the CA is in the file > /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt > > however no change. I have seen references to the ssl_crtd project however > from the examples I've seen that isn't required. is this my issue? > > Contents of my squid.conf file are below, would appreciate > # reverse proxy site > # > acl localnet src 10.0.0.0/8 > # - debug options > # 0 client database > # 1 start up and main loop > # 2 Unlink Daemon > # 3 configuration file parsing > # 4 error generation > # 5 socket functions > # 11 HTTP > # 23 URL parsing > debug_options All,1 9 > > > acl SSL_ports port 5443 > acl Safe_ports port 80 > acl Safe_ports port 21 > acl Safe_ports port 443 > acl Safe_ports port 8902 > acl Safe_ports port 70 > acl Safe_ports port 210 > acl Safe_ports port 280 > acl Safe_ports port 488 > acl Safe_ports port 591 > acl Safe_ports port 777 > acl Safe_ports port 5443 > acl Safe_ports port 1025-65535 > acl CONNECT method CONNECT > > > http_port 3128 transparent > > http_access allow Safe_ports > #http_access deny !Safe_ports > > http_access allow localnet > > > > > https_port 5443 accel defaultsite=10.234.48.183 > cert=/etc/squid/tls/devi_public.pem key=/etc/squid/tls/devi_private.key > cafile=/etc/squid/tls/devi_ca.crt vhost > > > sslproxy_options NO_SSLv2:NO_SSLv3:NO_TLSv1:NO_TLSv1_1 > > > > > cache_peer 10.234.49.188 parent 5443 0 no-query originserver ssl > sslflags=DONT_VERIFY_PEER connection-auth=off name=dev-api > > acl BrokenButTrustedServers dstdomain 10.234.49.188 devi.mlms.cms.gov > #sslproxy_cert_error allow BrokenButTrustedServers > sslproxy_cert_error allow all > #sslproxy_cert_error deny all > sslproxy_flags DONT_VERIFY_PEER > > #ssl_bump splice #localhost > # configure backend > > acl our_sites dstdomain dev.app.lb.local 10.234.49.188 > http_access allow our_sites > cache_peer_access dev-int allow our_sites > cache_peer_access dev-api allow our_sites > > > > -- > Sent from: > http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] squid 3.5 reverse proxy https configuration problem
I have a squid configured as a reverse proxy on RHEL 7.8 the certificates on the squid box seem okay the squid -k parse passes, however when I attempt to access the back-end server via squid I get Error negotiating SSL connection on FD 13: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown (1/0) It'd my understanding to resolve the SSL error I need to add the CA of the backend sever to the RHEL trust store - I have done that, copied the ca to /etc/pki/ca-trust/source/anchors/ ran update-ca-trust extract, confirmed the CA is in the file /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt however no change. I have seen references to the ssl_crtd project however from the examples I've seen that isn't required. is this my issue? Contents of my squid.conf file are below, would appreciate # reverse proxy site # acl localnet src 10.0.0.0/8 # - debug options # 0 client database # 1 start up and main loop # 2 Unlink Daemon # 3 configuration file parsing # 4 error generation # 5 socket functions # 11 HTTP # 23 URL parsing debug_options All,1 9 acl SSL_ports port 5443 acl Safe_ports port 80 acl Safe_ports port 21 acl Safe_ports port 443 acl Safe_ports port 8902 acl Safe_ports port 70 acl Safe_ports port 210 acl Safe_ports port 280 acl Safe_ports port 488 acl Safe_ports port 591 acl Safe_ports port 777 acl Safe_ports port 5443 acl Safe_ports port 1025-65535 acl CONNECT method CONNECT http_port 3128 transparent http_access allow Safe_ports #http_access deny !Safe_ports http_access allow localnet https_port 5443 accel defaultsite=10.234.48.183 cert=/etc/squid/tls/devi_public.pem key=/etc/squid/tls/devi_private.key cafile=/etc/squid/tls/devi_ca.crt vhost sslproxy_options NO_SSLv2:NO_SSLv3:NO_TLSv1:NO_TLSv1_1 cache_peer 10.234.49.188 parent 5443 0 no-query originserver ssl sslflags=DONT_VERIFY_PEER connection-auth=off name=dev-api acl BrokenButTrustedServers dstdomain 10.234.49.188 devi.mlms.cms.gov #sslproxy_cert_error allow BrokenButTrustedServers sslproxy_cert_error allow all #sslproxy_cert_error deny all sslproxy_flags DONT_VERIFY_PEER #ssl_bump splice #localhost # configure backend acl our_sites dstdomain dev.app.lb.local 10.234.49.188 http_access allow our_sites cache_peer_access dev-int allow our_sites cache_peer_access dev-api allow our_sites -- Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Bypass squid using iptables
B.H. I'm using squid with c-icap module for specific content filtering. I configured squid with ssl bump so website with WSS won't work on it as mentioned on squid documentation. So for such URLs (with WSS) I need bypassing squid. I read in some posts that squid doesn't fully supports bypassing URLs and best way is to bypasses it via iptables. Eventually I redirects browser traffic to my proxy machine using local machine proxy settings, and Its redirects traffic to my machine with IP x.x.x.x port 3128. If I want to use the conservative iptables bypassing how should I config my machine? and how iptables rules should looks like? Any help will be appreciated. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method
On 5/20/20 6:02 AM, Matus UHLAR - fantomas wrote: >> On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote: >>> David, note that requiring browsers to connect to your proxy over >>> encrypted (https) connection, and then decrypting tunnels to real server >>> will >>> lower the clients' security > On 19.05.20 10:46, Alex Rousskov wrote: >> A proper SslBump implementation for HTTPS proxy will not be "decrypting >> tunnels to real server". The security of such an implementation will be >> the same as of SslBump supported today (plus the additional protections >> offered by securing the browser-proxy communication). > If David wants to ssl-bump the traffic inside the HTTPS tunel, it means that > the > communication between browser and server has to be decrypted on squid, > squid will talk to server using HTTPS You are right. Due to insufficient shared terminology, we are simply talking about two different things: * I am talking about Squid (in a bumping HTTPS proxy role) sending bumped requests to plain servers, exposing previously encrypted traffic. While that is technically possible to support (in some cases) and even occasionally explicitly requested (in a peering environment), that should _not_ happen if the existing SslBump support is added to the existing HTTPS proxy mode. * You are talking about Squid (in a bumping HTTPS proxy role) inspecting TLS traffic that the client meant for to origin servers eyes only. That will happen, of course. This is what SslBump is about. > My point is that David wants to provide "secure" proxy which may compromise > the security instead by bumping connections. Right. And my point is that adding SslBump support to HTTPS proxy does not make things _worse_ as far as "security" and "privacy" are concerned. Compared to using SslBump in an HTTP proxy, adding SslBump support to HTTPS proxy may make things better. How much better depends on your threat model, of course. No sane person would argue that bumping is a good solution. My point was that if you have to bump, then using an HTTPS proxy is not going to make things worse. It would be better if popular browsers would send plain https://... URLs to an HTTPS proxy they trust, but they refuse to support that "GET https" mode. Cheers, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method
On 5/20/20 3:51 AM, David Touzeau wrote: > How to be a sponsor? There are many ways, including these two: 1. You privately find a developer (a person or an organization) and pay them for implementing the changes you need. 2. You post an RFQ to squid-dev and solicit quotes/bids from developers. If substantial changes you sponsored are officially accepted, you can request to be officially listed in SPONSORS. Needless to say, you can pull resources with other co-sponsors. For a complex feature like TLS-inside-TLS bumping, please make sure that a) The required architectural changes are deemed acceptable to the Squid Project before the development starts. Otherwise, you may end up with a large piece of code that you would have to pay somebody to maintain forever. Such preliminary acceptance can be secured via discussions on squid-dev. Such discussions should be initiated by (the developer) posting a Request For Comments outlining major anticipated changes. b) The developer will support the changes throughout Squid Project review and initial deployment. It is very likely that the initial version of the "working" code will need to be adjusted (for many reasons). The following FAQ may be useful in this context: https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F > ( cost ) of such feature That would be determined by the developer, subject to the usual business negotiations (warranties, deadlines, backporting support, payment terms, etc.). The most common pitfalls here are underestimating the complexity of the changes, the overheads related to getting the changes officially accepted, and medium-term support costs. FWIW, if I were to get a quote that equates this project with a week worth of work, I would laugh at it. Please note that the Squid Project itself does not do Squid development and does not receive any money for Squid development. Some developers contribute back to the Project (in various ways), but there is no requirement to do so. This is typical for many open source projects, of course. > Could you think it can be planned for 5.x ? IMO, no. The change is too big to qualify for any reasonable v5 freeze exception. Squid v6 is your best bet right now. If the developer knows what they are doing, there are ways to mitigate associated risks. HTH, Alex. > Le 19/05/2020 à 16:46, Alex Rousskov a écrit : On 18/05/20 10:15 am, David Touzeau wrote: > Hi we want to use squid as * * * Secure Proxy * * * using https_port > We have tested major browsers and it seems working good. > > To make it work, we need to deploy the proxy certificate on all browsers > to make the secure connection running. >> I hope that deployment is not necessary -- an HTTPS proxy should be >> using a certificate issued for its domain name and signed by a >> well-known CA already trusted by browsers. An HTTPS proxy is not faking >> anything. If browsers do require CA certificate import in this >> environment, it is their limitation. >> >> >> On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote: >>> David, note that requiring browsers to connect to your proxy over encrypted >>> (https) connection, and then decrypting tunnels to real server will lower >>> the clients' security >> A proper SslBump implementation for HTTPS proxy will not be "decrypting >> tunnels to real server". The security of such an implementation will be >> the same as of SslBump supported today (plus the additional protections >> offered by securing the browser-proxy communication). >> >> Cheers, >> >> Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Sending CONNECT method requests over HTTPS
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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Block file extension over https
On 20.05.20 07:13, Leonardo Bacha Abrantes wrote: Please does anyone has a effective way how to block file download over https connection? I tried many things but didn't work. Only worked over http. this requires SSL bumping. in https, you don't see the content unless you bump, and therefore decrypt the connection. It is not secure anymore. https://wiki.squid-cache.org/Features/SslPeekAndSplice -- Matus UHLAR - fantomas, uh...@fantomas.sk ; 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. Your mouse has moved. Windows NT will now restart for changes to take to take effect. [OK] ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Block file extension over https
Hi guys, Please does anyone has a effective way how to block file download over https connection? I tried many things but didn't work. Only worked over http. Sorry for my english. Thanks! ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Sending CONNECT method requests over HTTPS
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, uh...@fantomas.sk ; 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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method
On 18/05/20 10:15 am, David Touzeau wrote: Hi we want to use squid as * * * Secure Proxy * * * using https_port We have tested major browsers and it seems working good. To make it work, we need to deploy the proxy certificate on all browsers to make the secure connection running. On 19.05.20 10:46, Alex Rousskov wrote: I hope that deployment is not necessary -- an HTTPS proxy should be using a certificate issued for its domain name and signed by a well-known CA already trusted by browsers. An HTTPS proxy is not faking anything. If browsers do require CA certificate import in this environment, it is their limitation. That means, SSL connection from brower to the proxy will be encrypted and signed by certificate installed on the proxy, which may be signed by public authority, provided the proxy has public DNS name (public authorities only sign public domains) the traffic inside of the SSL tunnel will be standard proxy communication - GET, POST, CONNECT requests. CONNECT requests will ask the proxy to build tunnel to destination server, which will usually contain encrypted HTTPS communication between browser and final server. So, CONNECT will create HTTPS connection (browser-server) inside of HTTPS connection (browser-proxy) On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote: David, note that requiring browsers to connect to your proxy over encrypted (https) connection, and then decrypting tunnels to real server will lower the clients' security A proper SslBump implementation for HTTPS proxy will not be "decrypting tunnels to real server". The security of such an implementation will be the same as of SslBump supported today (plus the additional protections offered by securing the browser-proxy communication). If David wants to ssl-bump the traffic inside the HTTPS tunel (and I from Davis's request I believe he wants to do that), it means that the communication between browser and server has to be decrypted on squid, squid will talk to server using HTTPS and create HTTPS endpoint to the client that provides data, which means: - squid will see the communication between browser and server (which is what HTTPS is designed to avoid) - squid will need to dynamically creste certificated for sites it bumps using local CA - clients will need to install the CA as trusted. This is exactly what SSL Bump is about. My point is that David wants to provide "secure" proxy which may compromise the security instead by bumping connections. I am not objecting against doing it, but I want to note that whole point of HTTPS (where the "S" means secure) is that noone in the middle sees what is the content of communication between client and server. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; 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. On the other hand, you have different fingers. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method
Thanks for the answer details How to be a sponsor ? ( cost ) of such feature Could you think it can be planned for 5.x ? I think it should be a "future" "standard" in the same way of DNS over SSL Le 19/05/2020 à 16:46, Alex Rousskov a écrit : On 18/05/20 10:15 am, David Touzeau wrote: Hi we want to use squid as * * * Secure Proxy * * * using https_port We have tested major browsers and it seems working good. To make it work, we need to deploy the proxy certificate on all browsers to make the secure connection running. I hope that deployment is not necessary -- an HTTPS proxy should be using a certificate issued for its domain name and signed by a well-known CA already trusted by browsers. An HTTPS proxy is not faking anything. If browsers do require CA certificate import in this environment, it is their limitation. On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote: David, note that requiring browsers to connect to your proxy over encrypted (https) connection, and then decrypting tunnels to real server will lower the clients' security A proper SslBump implementation for HTTPS proxy will not be "decrypting tunnels to real server". The security of such an implementation will be the same as of SslBump supported today (plus the additional protections offered by securing the browser-proxy communication). Cheers, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
