Re: [squid-users] Squid Explicit Proxying
First, thank you very much for your help, you re awesome ! I can in fact browse HTTP pages, but not HTTPS. Can i ask you a bit more help :) ? I applied some changes : Regarding the certificate, i read the man page http://man.openbsd.org/ssl cd /etc/squid openssl genrsa -out squid.key 4096 openssl req -new -key squid.key -out squid.csr openssl x509 -sha256 -req -days 365 -in squid.csr -signkey squid.key -out squid.crt cat squid.crt squid.key > squid.pem chown _squid:_squid *.pem chmod 700 *.pem openssl x509 -in squid.pem -outform DER -out browser.der Now when i try : curl --proxy http://127.0.0.1:3128 --cacert /etc/squid/squid.pem -l https://www.google.com I get : curl: (60) SSL certificate problem: unable to get local issuer certificate... On the Windows 10 laptop, i configured the proxy using inetcpl.cpl see attached screenshot (IE options). I also added the browser.der to root certification in the snap certmgr.msc (see attached screenshot). On Firefox, I get SEC_ERROR_UNKNOWN_ISSUER when trying to browse https website. On Chrome, I get ERR_CONNECTION_CLOSED when trying to browse https website. HTTP website is OK. I enabled the debug in squid.conf like you suggested me :) Here the squid -k parse : --8<-- obsd-proxy# squid -k parse 2020/08/26 10:35:44| Startup: Initializing Authentication Schemes ... 2020/08/26 10:35:44| Startup: Initialized Authentication Scheme 'basic' 2020/08/26 10:35:44| Startup: Initialized Authentication Scheme 'digest' 2020/08/26 10:35:44| Startup: Initialized Authentication Scheme 'negotiate' 2020/08/26 10:35:44| Startup: Initialized Authentication Scheme 'ntlm' 2020/08/26 10:35:44| Startup: Initialized Authentication. 2020/08/26 10:35:44| Processing Configuration File: /etc/squid/squid.conf (depth 0) 2020/08/26 10:35:44| Processing: debug_options ALL,5 2020/08/26 10:35:44| Processing: acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN) 2020/08/26 10:35:44| Processing: acl localnet src 10.0.0.0/8 # RFC 1918 local private network (LAN) 2020/08/26 10:35:44| Processing: acl localnet src 100.64.0.0/10 # RFC 6598 shared address space (CGN) 2020/08/26 10:35:44| Processing: acl localnet src 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines 2020/08/26 10:35:44| Processing: acl localnet src 172.16.0.0/12 # RFC 1918 local private network (LAN) 2020/08/26 10:35:44| Processing: acl localnet src 192.168.0.0/16 # RFC 1918 local private network (LAN) 2020/08/26 10:35:44| Processing: acl localnet src fc00::/7 # RFC 4193 local private network range 2020/08/26 10:35:44| Processing: acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines 2020/08/26 10:35:44| Processing: acl SSL_ports port 443 2020/08/26 10:35:44| Processing: acl Safe_ports port 80 # http 2020/08/26 10:35:44| Processing: acl Safe_ports port 21 # ftp 2020/08/26 10:35:44| Processing: acl Safe_ports port 443 # https 2020/08/26 10:35:44| Processing: acl Safe_ports port 70 # gopher 2020/08/26 10:35:44| Processing: acl Safe_ports port 210 # wais 2020/08/26 10:35:44| Processing: acl Safe_ports port 1025-65535 # unregistered ports 2020/08/26 10:35:44| Processing: acl Safe_ports port 280 # http-mgmt 2020/08/26 10:35:44| Processing: acl Safe_ports port 488 # gss-http 2020/08/26 10:35:44| Processing: acl Safe_ports port 591 # filemaker 2020/08/26 10:35:44| Processing: acl Safe_ports port 777 # multiling http 2020/08/26 10:35:44| Processing: acl CONNECT method CONNECT 2020/08/26 10:35:44| Processing: http_access deny !Safe_ports 2020/08/26 10:35:44| Processing: http_access deny CONNECT !SSL_ports 2020/08/26 10:35:44| Processing: http_access allow localhost manager 2020/08/26 10:35:44| Processing: http_access deny manager 2020/08/26 10:35:44| Processing: acl bad_urls urlpath_regex -i "/etc/squid/bad_urls" 2020/08/26 10:35:44| Processing: acl bad_domains dstdomain "/etc/squid/bad_domains" 2020/08/26 10:35:44| Processing: http_access deny bad_urls 2020/08/26 10:35:44| Processing: http_access deny bad_domains 2020/08/26 10:35:44| Processing: http_access allow localnet 2020/08/26 10:35:44| Processing: http_access allow localhost 2020/08/26 10:35:44| Processing: http_access deny all 2020/08/26 10:35:44| Processing: http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB tls-cert=/etc/squid/squid.pem 2020/08/26 10:35:44| Processing: acl step1 at_step SslBump1 2020/08/26 10:35:44| Processing: ssl_bump peek step1 2020/08/26 10:35:44| Processing: acl step2 at_step SslBump2 2020/08/26 10:35:44| Processing: ssl_bump stare step2 2020/08/26 10:35:44| Processing: ssl_bump bump all 2020/08/26 10:35:44| Processing: sslcrtd_program /usr/local/libexec/squid/security_file_certgen -s /var/squid/ssl_db -M 4MB 2020/08/26 10:35:44| Processing: sslcrtd_children 5 2020/08/26 10:35:44|
Re: [squid-users] Squid Explicit Proxying
On 25/08/20 10:35 pm, Eric F. wrote: > Hi, > > I use OpenBSD 6.7 with Squid 4.12. > I want to filter http and https website, so i'm trying to use SSL bumping. > But unfortunately, my configuration doesn't work. I explain what i did: > > The host is named : proxy.lab.local > > I generated the certificate like that: > > cd /etc/squid > openssl req -new -newkey rsa:4096 -sha256 -days 365 -nodes -x509 -keyout > squid.pem -out squid.pem This creates keys. The public cert still needs to be signed. Though curl below indicates a self-signed cert is present in the chain it gets from Squid. That is a bit odd. > openssl x509 -in /etc/squid/squid.pem -outform DER -out > /etc/squid/browser.der This should be done after signing. Whether you do self-signed or not export the DER from the same file you put in the --CA parameter for the signing process. > chown _squid:_squid *.pem > > run squid with squid -z && rcctl start squid > > no errors. > > I installed the browser.der on my Windows 10 laptop (added the proxy), > therefore i can't access any webpage. Er. You should still be able to access web pages. The traffic should just be going via Squid if you "added the proxy" right. > > I tried on the squid server the following tests (curl) > > proxy# curl --proxy http://127.0.0.1:3128 https://www.google.com > curl: (60) SSL certificate problem: self signed certificate in > certificate chain > More details here: https://curl.haxx.se/docs/sslcerts.html curl on the proxy machine does not know about browser.der on the Windows machines. This is expected result. > > curl failed to verify the legitimacy of the server and therefore could not > establish a secure connection to it. To learn more about this situation and > how to fix it, please visit the web page mentioned above. > > proxy# curl --proxy http://127.0.0.1:3128 --cacert /etc/squid/squid.pem > -l https://www.google.com > curl: (35) error:1401E410:SSL routines:CONNECT_CR_FINISHED:sslv3 alert > handshake failure > The -l indicates an email or FTP server being connected to. Otherwise this command looks correct. I start by looking up the OpenSSL error message. Unfortunately that one produces no search results for me. You might have better luck. In absence of any useful info about what the error means next thing is to get the verbose output from curl to see what is going on. And check the Squid cache.log with "debug_options ALL,5" to see what Squid is doing at its end. If that does not provide more useful clues then TCP level packet trace in wireshark as a last resort. > Can you help me to troubleshoot this issue ? > > Thank you very much. > > Below my configuration : > > > proxy# squid -v > Squid Cache: Version 4.12 > Service Name: squid > > This binary uses LibreSSL 3.1.1. For legal restrictions on distribution > see https://www.openssl.org/source/license.html > FYI, LibreSSL is not formally supported due to the number of behavioural differences it now has with OpenSSL. SSL-Bump is a mix of custom Squid code and relatively low-level calls into OpenSSL. While LibreSSL usually builds, we cannot guarantee those low-level calls do what SSL-Bump expects. ... > > acl bad_urls urlpath_regex -i "/etc/squid/bad_urls" > acl bad_domains dstdomain "/etc/squid/bad_domains" > > http_access deny bad_urls > http_access deny bad_domains > > # > # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS > # > Nit: that line means all the bad_* checks should be down here. > # Example rule allowing access from your local networks. > # Adapt localnet in the ACL section to list your (internal) IP networks > # from where browsing should be allowed > http_access allow localnet > http_access allow localhost > > # And finally deny all other access to this proxy > http_access deny all > > # Squid normally listens to port 3128 > http_port 3128 ssl-bump \ > cert=/etc/squid/squid.pem \ Nit: the option is now named tls-cert= > generate-host-certificates=on dynamic_cert_mem_cache_size=8MB > > sslcrtd_program /usr/local/libexec/squid/security_file_certgen -s > /var/squid/ssl_db -M 8MB > > acl step1 at_step SslBump1 > ssl_bump peek step1 > ssl_bump bump all This makes SSL-Bump generate the certificates without any details from the actual server. You can expect a lot of issues with TLS features that need end-to-end negotiation (eg TLS/1.3 connections). To work around that: acl step1 at_step SslBump1 ssl_bump peek step1 acl step2 at_step SslBump2 ssl_bump stare step2 ssl_bump bump all > sslcrtd_children 5 > sslproxy_cert_sign signTrusted > HTH Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] GENEVE?
On 26/08/20 7:39 am, Alex Rousskov wrote: > On 8/25/20 3:21 PM, Jonas Steinberg wrote: > >> is this something I could submit as a feature request via github or >> is it too crazy or out-of-scope for the roadmap? > > I am not familiar with draft-ietf-nvo3-geneve details, but I see nothing > particularly crazy on the surface of that draft: Squid is already > capable of tunneling intercepted TLS and forwarded HTTP CONNECT traffic > while GENEVE seems like one more way to tell Squid about the desired > tunnel end points. > First thing that I notice is that GENEVE is UDP/IP based. HTTP CONNECT tunnels that Squid uses are for TCP based traffic. Taking a slightly deeper (but still brief) look through its protocol design I see just another IP based tunnel. There are hundreds of these already. This type of protocol is best handled by a regular router and/or firewall. As Alex said, Squid can be extended. But IMO this is not worth the effort. It would be better to wait on OS networking stacks to support the decapsulation. The OS can pass any relevant traffic to Squid via the regular socket APIs - like how GRE and IP-IP tunnels are supported. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] (71) Protocol error (TLS code: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT)
On 26/08/20 1:30 pm, m k wrote: > Hi team, > > Sorry for the many questions. > As an in-house SE, I plan to switch from Bluecoat to Squid. > ***I am Japanese. And I can not do English. > All are Google translations.*** > > I am doing a load test on Squid. > Apache Jmeter is loading the self-certified WEB server. > How can I test with a self-certified WEB server with Jmeter? > You can use cache_peer for custom connectivity to a server: cache_peer jmeter.local parent 443 0 originserver \ tls-cafile=/etc/squid/jmeter_ca_cert.pem \ tls-default-ca=off cache_peer_access jmeter.local allow ... never_direct allow ... Put the CA cert for jmeter in /etc/squid/jmeter_ca_cert.pem. FYI: it is best to keep the self-signed cert as your own private CA and give jmeter a normal server cert. Then you only have to change the jmeter config if its cert gets compromised or needs updating for any other reason. Squid can continue to use your self-signed CA to verify any server certs it signed for jmeter. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Strange Squid SSL Interception Behavior
On 26/08/20 10:39 am, Alex Rousskov wrote: > On 8/25/20 6:15 PM, Mathew Brown wrote: > >> http_access deny CONNECT !SSL_ports >> http_access allow localnet CONNECT > AIUI, this would be better if it works: http_access deny CONNECT !SSL_ports http_access allow CONNECT step1 Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] (71) Protocol error (TLS code: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT)
Hi team, Sorry for the many questions. As an in-house SE, I plan to switch from Bluecoat to Squid. ***I am Japanese. And I can not do English. All are Google translations.*** I am doing a load test on Squid. Apache Jmeter is loading the self-certified WEB server. How can I test with a self-certified WEB server with Jmeter? Squid server: -set SSL Bump -No authentication(no AD,no Basic) -Other https is OK(yahoo,google,etc) Web server: -Apache and ssl_mod installed -Registered in DNS -Created a self-signed certificate -Set the p12 file to Jmeter's SSL Manager Jmeter response header HTTP/1.1 503 Service Unavailable Server: squid/4.4 X-Squid-Error: ERR_SECURE_CONNECT_FAIL 71 response body (71) Protocol error (TLS code: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT) This proxy and the host to which it connects could not get security settings to handle your request, which are accepted by each other. The host you are connecting to may not support secure connections, or the proxy may not be able to meet the certificate requested by the host you are connecting to. Thank you, kitamura ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] GENEVE?
Any advice on where I would find such a protocol wrapper, were one to exist? Also I assume this would mean compiling my own squid then? Jonas Steinberg Software Engineer 3M HIS (remote) (702) 807-9888 On 8/25/20, 2:39 PM, "Alex Rousskov" wrote: On 8/25/20 3:21 PM, Jonas Steinberg wrote: > is this something I could submit as a feature request via github or > is it too crazy or out-of-scope for the roadmap? I am not familiar with draft-ietf-nvo3-geneve details, but I see nothing particularly crazy on the surface of that draft: Squid is already capable of tunneling intercepted TLS and forwarded HTTP CONNECT traffic while GENEVE seems like one more way to tell Squid about the desired tunnel end points. Perhaps some form of GENEVE support is already possible via some kind of 3rd-party wrappers? FWIW, the possible existence of such protocol wrappers was the primary reason I did not give a straight "no" answer to your original question... You may file a feature request on Squid Bugzilla, keeping the following FAQ in mind: https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F HTH, Alex. > On 8/25/20, 1:54 PM, Alex Rousskov wrote: > > On 8/25/20 2:43 PM, Jonas Steinberg wrote: > > Do recent versions of Squid support GENEVE? > > I believe Squid is unaware of draft-ietf-nvo3-geneve. > > Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] GENEVE?
Is there any way to definitively confirm this? Also is this something I could submit as a feature request via github or is it too crazy or out-of-scope for the roadmap? Jonas Steinberg Software Engineer 3M HIS (remote) (702) 807-9888 On 8/25/20, 1:54 PM, "Alex Rousskov" wrote: On 8/25/20 2:43 PM, Jonas Steinberg wrote: > Do recent versions of Squid support GENEVE? I believe Squid is unaware of draft-ietf-nvo3-geneve. Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] GENEVE?
Do recent versions of Squid support GENEVE? Thank you, Jonas Steinberg Software Engineer 3M HIS (remote) (702) 807-9888 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Strange Squid SSL Interception Behavior
On 8/25/20 6:15 PM, Mathew Brown wrote: > http_access deny CONNECT !SSL_ports > http_access allow localnet CONNECT > ssl_bump peek step1 > ssl_bump terminate !whitelist > ssl_bump splice all FYI: The above ssl_bump rules can be rewritten to avoid negation (which can have surprising/unwanted effects in error cases): ssl_bump peek step1 ssl_bump splice whitelist ssl_bump terminate all > The above allows access only to httpbin.org and no other domains Yes, in cases where "to httpbin.org" can be determined based on TCP client and TLS client handshake information. For example, if reverse DNS lookup do not work well, then the above rules will terminate TLS clients that omit TLS SNI information or that send fake/encrypted SNI, even if those clients are trying to establish a TLS connection with one of the httpbin.org servers. My example is not meant as a criticism of your configuration. Only as an additional information about that configuration effects. > If I understand correctly, the original issue is that the CONNECT has > to be allowed explicitly and it was not and because of this, it was > not be able to proceed in the SSL bumping path. Is my understanding > correct? Just one minor correction/clarification: It is best to think of Squid configuration as if _everything_ has to be allowed explicitly (rather than that something is allowed implicitly and some exceptional cases need special rules). For example, AFAICT, your current configuration allows local [fake] CONNECTs to safe ports (and nothing else). That access policy is fine if it matches your intent. The policy will stop working if you decide to bump and forward HTTPS traffic or forward plain text HTTP requests. HTH, Alex. > > *From:* Alex Rousskov > *Sent:* Tuesday, August 25, 2020 11:24 PM > *To:* Mathew Brown ; > squid-users@lists.squid-cache.org > *Subject:* Re: [squid-users] Strange Squid SSL Interception Behavior > > On 8/24/20 9:09 PM, Mathew Brown wrote: >> Thanks but even with the --no-check-certificate option and using a bump >> instead of splicing, it still fails as shown above unless I add the >> localnet rule. The question is: why does the same ACL line: > >> http_access allow whitelist > >> suddenly work when I add an unrelated ACL line after it? > > You are misinterpreting the outcome of the test. That whitelist > http_access line did not work (well) for fake CONNECTs before and does > not start working (well) after another http_access rule is added. It is > the added rule that "starts working" instead! > > Most ACL-driven directives, including http_access, cannot be correctly > interpreted at single-ACL, single-line, or single-rule scope. You must > consider _all_ rules for a given directive to correctly predict the > outcome of that directive evaluation. When you add a rule, the outcome > of the directive evaluation may change if the previous set of rules did > not match and the added rule does match. The latter is exactly what > happens in your "add an unrelated ACL" test case. > > For completeness sake: When no http_access rules match, Squid applies > the action (allow or deny) that is the opposite of the last configured > http_access rule action. If no http_access rules were configured at all, > Squid denies. > > > There is similar (albeit a bit incomplete) information in the (arguably > misplaced) FAQ section at > https://wiki.squid-cache.org/SquidFaq/SquidAcl#Access_Lists > > >> From my understanding, Squid should perform the exact same steps in both >> cases BUT then allow the connection because of the localnet ACL line >> that it sees right before the deny all line, not because it suddenly was >> able to match httpbin.org using a domain compare as shown by the debug >> logs. What am I missing? > > You may also be missing the fact that http_access directive is applied > several times for one wget execution, once at every SslBump step. The > information available to Squid at each SslBump step differs. > https://wiki.squid-cache.org/Features/SslPeekAndSplice > > Domain-based ACL matches you see in the second test log probably do not > exist in the first test because Squid does not get far enough during the > first test -- Squid denies the fake CONNECT (and bumps the connection) > at step1, when no domain information is available yet. > > > HTH, > > Alex. > > >> >> *From:* Alex Rousskov >> *Sent:* Tuesday, August 25, 2020 8:41 AM >> *To:* Mathew Brown ; >> squid-users@lists.squid-cache.org >> *Subject:* Re: [squid-users] Strange Squid SSL Interception Behavior >> >> On 8/24/20 6:21 PM, Mathew Brown wrote: >> >>> acl whitelist ssl::server_name .httpbin.org >>> acl whitelist_http ssl::server_name .httpbin.org >> >>> ssl_bump peek step1 >>> ssl_bump splice all >> >>> http_access allow whitelist >>> http_access allow whitelist_http >>> http_acces
Re: [squid-users] Strange Squid SSL Interception Behavior
Thank you Alex for your patience and clarification. After reading your explanation and based on my limited understanding, I was able to get the following to work: ... acl whitelist ssl::server_name .httpbin.org ... http_access deny CONNECT !SSL_ports http_access allow localnet CONNECT acl step1 at_step SslBump1 ssl_bump peek step1 ssl_bump terminate !whitelist ssl_bump splice all The above allows access only to httpbin.org and no other domains If I understand correctly, the original issue is that the CONNECT has to be allowed explicitly and it was not (I just had the typical DENY for non SSL ports) and because of this, it was not be able to proceed in the SSL bumping path. Is my understanding correct? Thanks From: Alex Rousskov Sent: Tuesday, August 25, 2020 11:24 PM To: Mathew Brown ; squid-users@lists.squid-cache.org Subject: Re: [squid-users] Strange Squid SSL Interception Behavior On 8/24/20 9:09 PM, Mathew Brown wrote: > Thanks but even with the --no-check-certificate option and using a bump > instead of splicing, it still fails as shown above unless I add the > localnet rule. The question is: why does the same ACL line: > http_access allow whitelist > suddenly work when I add an unrelated ACL line after it? You are misinterpreting the outcome of the test. That whitelist http_access line did not work (well) for fake CONNECTs before and does not start working (well) after another http_access rule is added. It is the added rule that "starts working" instead! Most ACL-driven directives, including http_access, cannot be correctly interpreted at single-ACL, single-line, or single-rule scope. You must consider _all_ rules for a given directive to correctly predict the outcome of that directive evaluation. When you add a rule, the outcome of the directive evaluation may change if the previous set of rules did not match and the added rule does match. The latter is exactly what happens in your "add an unrelated ACL" test case. For completeness sake: When no http_access rules match, Squid applies the action (allow or deny) that is the opposite of the last configured http_access rule action. If no http_access rules were configured at all, Squid denies. There is similar (albeit a bit incomplete) information in the (arguably misplaced) FAQ section at https://wiki.squid-cache.org/SquidFaq/SquidAcl#Access_Lists > From my understanding, Squid should perform the exact same steps in both > cases BUT then allow the connection because of the localnet ACL line > that it sees right before the deny all line, not because it suddenly was > able to match httpbin.org using a domain compare as shown by the debug > logs. What am I missing? You may also be missing the fact that http_access directive is applied several times for one wget execution, once at every SslBump step. The information available to Squid at each SslBump step differs. https://wiki.squid-cache.org/Features/SslPeekAndSplice Domain-based ACL matches you see in the second test log probably do not exist in the first test because Squid does not get far enough during the first test -- Squid denies the fake CONNECT (and bumps the connection) at step1, when no domain information is available yet. HTH, Alex. > > *From:* Alex Rousskov > *Sent:* Tuesday, August 25, 2020 8:41 AM > *To:* Mathew Brown ; > squid-users@lists.squid-cache.org > *Subject:* Re: [squid-users] Strange Squid SSL Interception Behavior > > On 8/24/20 6:21 PM, Mathew Brown wrote: > >> acl whitelist ssl::server_name .httpbin.org >> acl whitelist_http ssl::server_name .httpbin.org > >> ssl_bump peek step1 >> ssl_bump splice all > >> http_access allow whitelist >> http_access allow whitelist_http >> http_access deny all > > The rules above only allow CONNECT requests to .httpbin.org domains. > > During step1, when Squid intercepts a TLS connection to an IP address of > an .httpbin.org domain, Squid http_access rules are applied to a (fake) > CONNECT request to the destination IP address. There are no domain names > at that TCP-level bumping stage. Thus, you place your Squid at the mercy > of reverse DSN lookups. > > In my environment, reverse DNS does not work for httpbin.org the way you > may expect: > >> $ host 54.236.246.173 >> 173.246.236.54.in-addr.arpa domain name pointer >> ec2-54-236-246-173.compute-1.amazonaws.com. > > The above AWS domain name does not match your whitelist ACLs, of course, > and, hence, the fake CONNECT request is denied. Denied requests are > bumped to deliver the error message. Bumped requests require > --no-check-certificate or other means of trusting Squid's CA certificate. > > If you cannot explicitly allow CONNECT requests to httpbin.org IP > addresses (e.g., because they change too often), then consider allowing > CONNECT to safe ports at any address at step1. If you only intercept > connections to httpbin.org IPs, then you can probab
Re: [squid-users] GENEVE?
Em 25/08/2020 16:21, Jonas Steinberg escreveu: Is there any way to definitively confirm this? Also is this something I could submit as a feature request via github or is it too crazy or out-of-scope for the roadmap? And please never forget that if you need some feature that is not there yet, you can always sponsor the dev team to develop it :) -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] GENEVE?
On 8/25/20 3:48 PM, Jonas Steinberg wrote: > Any advice on where I would find such a protocol wrapper, were one to exist? Sorry, I do not know enough about GENEVE to suggest GENEVE-specific tool aggregators. > Also I assume this would mean compiling my own squid then? I would expect Squid to be unaware of that 3rd-party protocol wrapper. For example, you are probably familiar with stunnel that "wraps" plain-text TCP traffic into TLS, enabling TLS-unaware applications to "support" TLS. I speculate one could create a tool that wraps GENEVE traffic into HTTP CONNECT transactions that GENEVE-unaware HTTP proxies like Squid can tunnel. Alex. > On 8/25/20, 2:39 PM, Alex Rousskov wrote: > > On 8/25/20 3:21 PM, Jonas Steinberg wrote: > > > is this something I could submit as a feature request via github or > > is it too crazy or out-of-scope for the roadmap? > > I am not familiar with draft-ietf-nvo3-geneve details, but I see nothing > particularly crazy on the surface of that draft: Squid is already > capable of tunneling intercepted TLS and forwarded HTTP CONNECT traffic > while GENEVE seems like one more way to tell Squid about the desired > tunnel end points. > > Perhaps some form of GENEVE support is already possible via some kind of > 3rd-party wrappers? FWIW, the possible existence of such protocol > wrappers was the primary reason I did not give a straight "no" answer to > your original question... > > > You may file a feature request on Squid Bugzilla, keeping the following > FAQ in mind: > > https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F > > > HTH, > > Alex. > > > > On 8/25/20, 1:54 PM, Alex Rousskov wrote: > > > > On 8/25/20 2:43 PM, Jonas Steinberg wrote: > > > Do recent versions of Squid support GENEVE? > > > > I believe Squid is unaware of draft-ietf-nvo3-geneve. > > > > 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] GENEVE?
On 8/25/20 3:21 PM, Jonas Steinberg wrote: > is this something I could submit as a feature request via github or > is it too crazy or out-of-scope for the roadmap? I am not familiar with draft-ietf-nvo3-geneve details, but I see nothing particularly crazy on the surface of that draft: Squid is already capable of tunneling intercepted TLS and forwarded HTTP CONNECT traffic while GENEVE seems like one more way to tell Squid about the desired tunnel end points. Perhaps some form of GENEVE support is already possible via some kind of 3rd-party wrappers? FWIW, the possible existence of such protocol wrappers was the primary reason I did not give a straight "no" answer to your original question... You may file a feature request on Squid Bugzilla, keeping the following FAQ in mind: https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F HTH, Alex. > On 8/25/20, 1:54 PM, Alex Rousskov wrote: > > On 8/25/20 2:43 PM, Jonas Steinberg wrote: > > Do recent versions of Squid support GENEVE? > > I believe Squid is unaware of draft-ietf-nvo3-geneve. > > Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] GENEVE?
On 8/25/20 2:43 PM, Jonas Steinberg wrote: > Do recent versions of Squid support GENEVE? I believe Squid is unaware of draft-ietf-nvo3-geneve. Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Strange Squid SSL Interception Behavior
On 8/24/20 9:09 PM, Mathew Brown wrote: > Thanks but even with the --no-check-certificate option and using a bump > instead of splicing, it still fails as shown above unless I add the > localnet rule. The question is: why does the same ACL line: > http_access allow whitelist > suddenly work when I add an unrelated ACL line after it? You are misinterpreting the outcome of the test. That whitelist http_access line did not work (well) for fake CONNECTs before and does not start working (well) after another http_access rule is added. It is the added rule that "starts working" instead! Most ACL-driven directives, including http_access, cannot be correctly interpreted at single-ACL, single-line, or single-rule scope. You must consider _all_ rules for a given directive to correctly predict the outcome of that directive evaluation. When you add a rule, the outcome of the directive evaluation may change if the previous set of rules did not match and the added rule does match. The latter is exactly what happens in your "add an unrelated ACL" test case. For completeness sake: When no http_access rules match, Squid applies the action (allow or deny) that is the opposite of the last configured http_access rule action. If no http_access rules were configured at all, Squid denies. There is similar (albeit a bit incomplete) information in the (arguably misplaced) FAQ section at https://wiki.squid-cache.org/SquidFaq/SquidAcl#Access_Lists > From my understanding, Squid should perform the exact same steps in both > cases BUT then allow the connection because of the localnet ACL line > that it sees right before the deny all line, not because it suddenly was > able to match httpbin.org using a domain compare as shown by the debug > logs. What am I missing? You may also be missing the fact that http_access directive is applied several times for one wget execution, once at every SslBump step. The information available to Squid at each SslBump step differs. https://wiki.squid-cache.org/Features/SslPeekAndSplice Domain-based ACL matches you see in the second test log probably do not exist in the first test because Squid does not get far enough during the first test -- Squid denies the fake CONNECT (and bumps the connection) at step1, when no domain information is available yet. HTH, Alex. > > *From:* Alex Rousskov > *Sent:* Tuesday, August 25, 2020 8:41 AM > *To:* Mathew Brown ; > squid-users@lists.squid-cache.org > *Subject:* Re: [squid-users] Strange Squid SSL Interception Behavior > > On 8/24/20 6:21 PM, Mathew Brown wrote: > >> acl whitelist ssl::server_name .httpbin.org >> acl whitelist_http ssl::server_name .httpbin.org > >> ssl_bump peek step1 >> ssl_bump splice all > >> http_access allow whitelist >> http_access allow whitelist_http >> http_access deny all > > The rules above only allow CONNECT requests to .httpbin.org domains. > > During step1, when Squid intercepts a TLS connection to an IP address of > an .httpbin.org domain, Squid http_access rules are applied to a (fake) > CONNECT request to the destination IP address. There are no domain names > at that TCP-level bumping stage. Thus, you place your Squid at the mercy > of reverse DSN lookups. > > In my environment, reverse DNS does not work for httpbin.org the way you > may expect: > >> $ host 54.236.246.173 >> 173.246.236.54.in-addr.arpa domain name pointer >> ec2-54-236-246-173.compute-1.amazonaws.com. > > The above AWS domain name does not match your whitelist ACLs, of course, > and, hence, the fake CONNECT request is denied. Denied requests are > bumped to deliver the error message. Bumped requests require > --no-check-certificate or other means of trusting Squid's CA certificate. > > If you cannot explicitly allow CONNECT requests to httpbin.org IP > addresses (e.g., because they change too often), then consider allowing > CONNECT to safe ports at any address at step1. If you only intercept > connections to httpbin.org IPs, then you can probably relax your step1 > http_access rules to allow all CONNECTs (to safe addresses). > > There are many similar questions about allowing CONNECT to IP addresses > on this mailing list. You may be able to find more detailed advice or > instructions by searching for those mailing list threads. > > > HTH, > > Alex. > > >> $ wget https://httpbin.org >> --2020-08-24 17:48:34-- https://httpbin.org/ >> Resolving httpbin.org (httpbin.org)... 54.236.246.173, 3.220.112.94 >> Connecting to httpbin.org (httpbin.org)|54.236.246.173|:443... connected. >> ERROR: cannot verify httpbin.org's certificate, issued by ‘O=Internet >> Widgits Pty Ltd,ST=Some-State,C=AU’: >> Self-signed certificate encountered. >> To connect to httpbin.org insecurely, use `--no-check-certificate'. >> >> $ wget https://httpbin.org --no-check-certificate >> --2020-08-24 17:48:40-- https://httpbin.org/ >> Resolving httpbin.org (httpbin.org)... 3.220.112.94,
[squid-users] Squid Explicit Proxying
Hi, I use OpenBSD 6.7 with Squid 4.12. I want to filter http and https website, so i'm trying to use SSL bumping. But unfortunately, my configuration doesn't work. I explain what i did: The host is named : proxy.lab.local I generated the certificate like that: cd /etc/squid openssl req -new -newkey rsa:4096 -sha256 -days 365 -nodes -x509 -keyout squid.pem -out squid.pem openssl x509 -in /etc/squid/squid.pem -outform DER -out /etc/squid/browser.der chown _squid:_squid *.pem run squid with squid -z && rcctl start squid no errors. I installed the browser.der on my Windows 10 laptop (added the proxy), therefore i can't access any webpage. I tried on the squid server the following tests (curl) proxy# curl --proxy http://127.0.0.1:3128 https://www.google.com curl: (60) SSL certificate problem: self signed certificate in certificate chain More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. proxy# curl --proxy http://127.0.0.1:3128 --cacert /etc/squid/squid.pem -l https://www.google.com curl: (35) error:1401E410:SSL routines:CONNECT_CR_FINISHED:sslv3 alert handshake failure Can you help me to troubleshoot this issue ? Thank you very much. Below my configuration : proxy# squid -v Squid Cache: Version 4.12 Service Name: squid This binary uses LibreSSL 3.1.1. For legal restrictions on distribution see https://www.openssl.org/source/license.html configure options: '--disable-strict-error-checking' '--disable-arch-native' '--datadir=/usr/local/share/squid' '--libexecdir=/usr/local/libexec/squid' '--disable-loadable-modules' '--enable-arp-acl' '--enable-auth' '--enable-delay-pools' '--enable-digest' '--enable-follow-x-forwarded-for' '--enable-forw-via-db' '--enable-http-violations' '--enable-icap-client' '--enable-ipv6' '--enable-referer-log' '--enable-removal-policies=lru heap' '--enable-ssl' '--enable-ssl-crtd' '--with-openssl' '--enable-storeio=aufs ufs diskd' '--with-default-user=_squid' '--with-filedescriptors=8192' '--with-krb5-config=no' '--with-pidfile=/var/run/squid.pid' '--with-pthreads' '--with-swapdir=/var/squid/cache' '--disable-pf-transparent' '--enable-ipfw-transparent' '--enable-external-acl-helpers=SQL_session file_userip time_quota unix_group wbinfo_group LDAP_group eDirectory_userip' '--prefix=/usr/local' '--sysconfdir=/etc/squid' '--mandir=/usr/local/man' '--infodir=/usr/local/info' '--localstatedir=/var/squid' '--disable-silent-rules' '--disable-gtk-doc' 'CC=cc' 'CFLAGS=-O2 -pipe' 'LDFLAGS=-L/usr/local/lib' 'CPPFLAGS=-I/usr/local/include' 'CXX=c++' 'CXXFLAGS=-O2 -pipe' proxy# cat /etc/squid/squid.conf # # Recommended minimum configuration: # # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN) acl localnet src 10.0.0.0/8 # RFC 1918 local private network (LAN) acl localnet src 100.64.0.0/10 # RFC 6598 shared address space (CGN) acl localnet src 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines acl localnet src 172.16.0.0/12 # RFC 1918 local private network (LAN) acl localnet src 192.168.0.0/16 # RFC 1918 local private network (LAN) acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # # Recommended minimum Access Permission configuration: # # Deny requests to certain unsafe ports http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports # Only allow cachemgr access from localhost http_access allow localhost manager http_access deny manager acl bad_urls urlpath_regex -i "/etc/squid/bad_urls" acl bad_domains dstdomain "/etc/squid/bad_domains" http_access deny bad_urls http_access deny bad_domains # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed http_access allow localnet http_access allow localhost # And finally deny all other access to this proxy http_access deny all # Squ
Re: [squid-users] Need squid latest version 4.13 RPM packaged files for centos7 and x86_64 architecture
On 25/08/20 1:14 pm, Rafał Stanilewicz wrote: > >>> If for some reason many think that these RPM’s can pop up from /dev/null I >>> believe they are wrong. > > Actually, many people do build Squid by themselves successfully, and are > willing to share the builds. > > Myself, I have slightly older version than the OP requested, so I cannot > help, but I see there is some build available at > https://cbs.centos.org/koji/buildinfo?buildID=26092 (I cannot tell > anything about quality of the build, of course). > > Rafal > > > PS. I wish there was some central repo with binary builds of squid for > multiple linux distros, verified by community and available for > everyone. But now THIS requires some CPU, RAM, food and paying the > bills, so we cannot have it easily. > FYI, Eliezer has been providing such a repository at his own expense for some years now. Due to the large number of OS he supports in that repo it takes time to test and verify each package. I suggest anyone happy to help collaborate with him. Amos > On Tue, 25 Aug 2020 at 00:45, Eliezer Croitor wrote: > > Trying to understand something in the list. > > __ __ > > Anyone interested funding the build of these RPM’s? > > To power up some CPU, RAM etc requires food and other bills.. > > If for some reason many think that these RPM’s can pop up from > /dev/null I believe they are wrong. > > __ __ > > Let Me Know. > > __ __ > > Eliezer > ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Ubuntu 18 LTS repository for Squid 4.13 (rebuilt with sslbump support from sources in Debian unstable)
Hello everyone, The online repository with latest Squid 4.13 (rebuilt from Debian unstable with sslbump support) for Ubuntu 18 LTS 64-bit is available at squid413.diladele.com. Github repo at https://github.com/diladele/squid-ubuntu contains the scripts we used to make this compilation. Scripts for Ubuntu 20 and Ubuntu 16 are also available in that repo. Here are simple instructions how to use the repo. For more information see readme at https://github.com/diladele/squid-ubuntu . # add diladele apt key wget -qO - http://packages.diladele.com/diladele_pub.asc | sudo apt-key add - # add repo echo "deb http://squid413.diladele.com/ubuntu/ bionic main" > /etc/apt/sources.list.d/squid413.diladele.com.list # update the apt cache apt-get update # install apt-get install squid-common apt-get install squid apt-get install squidclient Hope you will find this useful. Note that older repo of squid412.diladele.com will be taken down today (due to sslbump issues with Chrome fixed in Squid 4.13). Best regards, Rafael Akchurin Diladele B.V. -- The same Squid 4.13 will be part of upcoming Web Safety 7.5 planned for release in November, this version has more improvements in the report generation module (upload reporting) and other various small fixes. Download the latest virtual appliance from https://docs.diladele.com/index.html ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Strange Squid SSL Interception Behavior
On 25/08/20 1:09 pm, Mathew Brown wrote: > Thanks but even with the --no-check-certificate option and using a bump > instead of splicing, it still fails as shown above unless I add the > localnet rule. The question is: why does the same ACL line: > > http_access allow whitelist > > suddenly work when I add an unrelated ACL line after it (http_access > allow localnet)? Why does it correctly determine the domain httpbin.org > in the later case as shown by cache.log? > The email from Alex Alex you are replying to already answers both those questions completely. > *From:* Alex Rousskov ... > > The rules above only allow CONNECT requests to .httpbin.org domains. > > During step1, when Squid intercepts a TLS connection to an IP address of > an .httpbin.org domain, Squid http_access rules are applied to a (fake) > CONNECT request to the destination IP address. There are no domain names > at that TCP-level bumping stage. Thus, you place your Squid at the mercy > of reverse DSN lookups. > > In my environment, reverse DNS does not work for httpbin.org the way you > may expect: > >> $ host 54.236.246.173 >> 173.246.236.54.in-addr.arpa domain name pointer >> ec2-54-236-246-173.compute-1.amazonaws.com. > > The above AWS domain name does not match your whitelist ACLs, of course, > and, hence, the fake CONNECT request is denied. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
