Re: [squid-users] Issues with ssl-bump in 3.HEAD
On 6/12/2014 6:04 PM, Eliezer Croitoru wrote: On 06/13/2014 01:04 AM, Mike wrote: So I re-add it for testing: http_port 3128 NP: forward-proxy traffic no bumping http_port 3129 intercept ssl-bump... blah blah ... and port 80 intercepted traffic and bumping CONNECT requests... ... CONNECT is not a valid method in port 80 traffic. Thus Eliezer says: You cannot use this and the cache.log will tell you that... Try to setup the server like this: http_port 3128 NP: forward-proxy traffic no bumping http_port 13129 intercept ... and port 80 intercepted traffic https_port 13130 intercept ssl-bump ... ... and port 443 intercepted traffic having its TLS bumped. With just basic settings. And still it looks like a look so what are the iptables rules you are using? On 13/06/2014 2:36 p.m., Mike wrote: So then next question is how do I know for sure ssl-bump is working? You will see https:// URLs logged in access.log as the bumped traffic gets served. When its fails you will get only CONNECT requests in access.log, maybe also TLS/SSL errors in cache.log. So far all the certificates match the servers, and I am able to use acls like 'acl blacklist1 dstdom_regex -i /etc/blacklists/dom_bl' to block domains, even if it is a secure site... but overall I have not figured out how to tell if ssl-bump is actually working or not. dstdom* ACLs results can vary depending on whether rDNS is known to Squid. If you want to use ACLs to test working ssl-bump you need to use some detail such as path which is fully encrypted and requires the bump to have succeeded to even test. Easier is to eyeball the access.log contents though. Amos
Re: [squid-users] How can I make squid ignore cached DNS looks up ?
On 13/06/2014 12:29 p.m., Mark jensen wrote: About the Note: Note that it is BAD practice to change a zone file entry more often than *daily*. Reseting PTR records every 1 minute or less will screw up in a great many systems, Squid is just one. Is it so bad if the system is a small system ( consist of 500 users) YMMV on how bad. Every request which is slowed down while re-fetching DNS results (necessary or not) is added annoyance for the clients waiting on those results and indirectly for all the other clients who may be needing to use the proxy CPU and RAM resources for other traffic. Amos
[squid-users] redirector/rewriter help
I'm using squid 3.1.20 on Debian. Trying to figure out what I need to do to cache redirected content. For example, I'm trying to download a file with a generic URL. The download site redirects (302) the generic URL to one of its various mirrors. Problem is each time I hit that URL with a different client, it's a different download because the mirror site changes. How do I configure squid to cache the downloaded file based on the generic URL rather than on the redirected URL? Thanks for any pointers to any relevant resources.
[squid-users] Re: redirector/rewriter help
StoreID should help you; may be together with a special helper. There are a few examples in the wiki. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/redirector-rewriter-help-tp4666339p4666340.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Issues with ssl-bump in 3.HEAD
On 06/12/2014 08:36 PM, Mike wrote: So then next question is how do I know for sure ssl-bump is working? A simple test is to look at the root CA certificate shown by the browser at the *top* of the certificate chain for a secure (https) site. Please note that you should not be looking at the site certificate. You should be looking at the certificate that was used to sign the site certificate (or the certificate that was used to sign the certificate that was used to sign the site certificate, etc. -- go to the root of the certificate chain). If that root certificate is yours, then the site was bumped. If it is an official root CA from a well-known company, the site was not bumped. To check SslBump for many sites, you have to examine Squid logs which is more difficult, especially if you test this with a mix of secure and insecure traffic. HTH, Alex.
Re: [squid-users] Issues with ssl-bump in 3.HEAD
On 6/13/2014 10:02 AM, Alex Rousskov wrote: On 06/12/2014 08:36 PM, Mike wrote: So then next question is how do I know for sure ssl-bump is working? A simple test is to look at the root CA certificate shown by the browser at the *top* of the certificate chain for a secure (https) site. Please note that you should not be looking at the site certificate. You should be looking at the certificate that was used to sign the site certificate (or the certificate that was used to sign the certificate that was used to sign the site certificate, etc. -- go to the root of the certificate chain). If that root certificate is yours, then the site was bumped. If it is an official root CA from a well-known company, the site was not bumped. To check SslBump for many sites, you have to examine Squid logs which is more difficult, especially if you test this with a mix of secure and insecure traffic. HTH, Alex. If thats the case then ssl-bump is not working. The root certificates all show the mainstream companies, Digicert, Godaddy, Verisign, etc. Mike
[squid-users] Re: squid with qlproxy on fedora 20 not working for https traffic
So if i want to ssl_bump only google, will the following statements work? acl https_targets dstdomain .google.com ssl_bump server-first https_targets I already tried it, and they don't seem to work. What would be a working configuration if i wanted only google.com to be bumped? ssl_bump server-first all, works but it bogs down squid and this slows down the internet. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-with-qlproxy-on-fedora-20-not-working-for-https-traffic-tp4666277p4666343.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] Fwd: gmail.com certificate name mismatch
I have squid 3.3.10 setup with sslbump working for all sites except when a user tries to type in gmail.com. For some reason the browser complains about certificate name mismatch. On examination the generated cert is actually for mail.google.com. Apparently google is redirecting buy why does this error happen only with sslbump. Anyone else have this issue, workarounds? Thanks in advance!
[squid-users] Squid+openbsd 5.5 on sparc 64
OpenBSD 5.5-stable (GENERIC.MP) #1: Thu Jun 12 18:57:48 EDT 2014 mb...@proxy.home:/usr/src/sys/arch/sparc64/compile/GENERIC.MP real mem = 17045651456 (16256MB) avail mem = 16759693312 (15983MB) mainbus0 at root: SPARC Enterprise T5220 ./configure --prefix=/usr/local/squid --with-filedescriptors=32768 --enable-snmp --with-large-files No errors Run make after 40 min, po -c -o client_side.o client_side.cc mv -f $depbase.Tpo $depbase.Po depbase=`echo client_side_reply.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`; g++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\/usr/local/squid/etc/squid.conf\ -DDEFAULT_SQUID_DATA_DIR=\/usr/local/squid/share\ -DDEFAULT_SQUID_CONFIG_DIR=\/usr/local/squid/etc\ -I.. -I../include -I../lib -I../src -I../include -I/usr/include/kerberosV -I/usr/include/kerberosV -I../libltdl -I../src -I../libltdl -I/usr/include/kerberosV -I/usr/include/kerberosV -I/usr/include/kerberosV -I/usr/include/kerberosV -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Werror -pipe -D_REENTRANT -g -O2 -MT client_side_reply.o -MD -MP -MF $depbase.Tpo -c -o client_side_reply.o client_side_reply.cc mv -f $depbase.Tpo $depbase.Po cc1plus: warnings being treated as errors client_side_reply.cc: In member function 'void clientReplyContext::buildReplyHeader()': client_side_reply.cc:1326: warning: format '%ld' expects type 'long int', but argument 4 has type 'long long int' *** Error 1 in src (Makefile:6970 'client_side_reply.o') *** Error 1 in src (Makefile:7116 'all-recursive') *** Error 1 in src (Makefile:6036 'all') *** Error 1 in /home/mbaki/squid-3.4.5 (Makefile:587 'all-recursive') Thanks
Re: [squid-users] Re: squid with qlproxy on fedora 20 not working for https traffic
On 14/06/2014 4:44 a.m., MrErr wrote: So if i want to ssl_bump only google, will the following statements work? acl https_targets dstdomain .google.com ssl_bump server-first https_targets I already tried it, and they don't seem to work. What would be a working configuration if i wanted only google.com to be bumped? Identify all the IP addresses used by Google and create a dst ACL from them. ssl_bump server-first all, works but it bogs down squid and this slows down the internet. The price of TLS is increased resource usage and slower traffic. The use of a proxy to decrypt and re-encrypt along the way doubles the requirements and halves the speed. Amos
[squid-users] Re: squid with qlproxy on fedora 20 not working for https traffic
Does this mean that dstdomain does not work with ssl-bump? My other reason for not using ssl-bump server-first all is that the kindle fire stops working. I read that it was because of something called ssl pinning. So i do need to get some kind of targeted bumping to happen. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-with-qlproxy-on-fedora-20-not-working-for-https-traffic-tp4666277p4666347.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Re: squid with qlproxy on fedora 20 not working for https traffic
On 14/06/2014 1:23 p.m., MrErr wrote: Does this mean that dstdomain does not work with ssl-bump? Yes and no. It works with CONNECT bumping in regular proxy traffic. It does not work on intercepted port 443 traffic reliably. My other reason for not using ssl-bump server-first all is that the kindle fire stops working. I read that it was because of something called ssl pinning. So i do need to get some kind of targeted bumping to happen. HSTS probably. And yes those sites bumping does not work for. Amos
