RE: [squid-users] Squid 3.4.5 is available
C++11 with the requirement for gcc-4.8 would really be a show-stopper for most existing systems... For example RHEL6 still ships with gcc-4.4.7, so a switch there would result in cutting off Centos/RHEL6 as well. Even the Debian I have running on my Raspberry Pi only comes with gcc-4.7.2 as the latest installable option. Only RHEL7beta ships with 4.8 as far as I can tell. And for that to go mainstream one will need to wait at least another year after the official release (which is probably in Q3-2014). So that would definitely reduce possible audience for any squid 3.5 release that makes use of C++11. And having people compile gcc and the required dependencies themselves first is another support-nightmare... I guess People would more likely stay with the older squid version (even if they are buggy) than spending that amount of time and Hassle just to get all the dependencies compiled or even think of upgrading to a new OS version... Out of curiosity: which features of c++11 do you want to use to make gcc 4.8 an absolute requirement for the next major release? Just my 2 cents Martin -Original Message- From: Amos Jeffries [mailto:squ...@treenet.co.nz] Sent: Montag, 05. Mai 2014 17:14 To: squid-users@squid-cache.org Subject: Re: [squid-users] Squid 3.4.5 is available On 6/05/2014 2:09 a.m., Martin Sperl wrote: Hi Amos! Does this mean that squid 3.4.4 is no longer supported on RedHat Enterprise/Centos 5 (ships with autoconf 2.59)? RHEL 6 comes with exactly 2.63, so any future update will mean that RHEL6 may also become unsupported as well. That OS version has been best-effort for some months now. We aim to test on the latest stable, previous stable, and if possible and upcoming/rolling release when we can. For CentOS we test on CentOS 6 and 6.5. Just tracking upstream authconf is bound to produce similar pains that I have already experienced with RRDTool on RH3, RH4, RH5 systems. Yes. We are not tracking autoconf upstream itself, but the packaging is now done on a Debian based machine which does have more frequent toolchain updates than our previous FreeBSD 5 machine. On the other hand the C++11 usage is more likely to have an blocking impact on those old RHEL systems. Do they have GCC 4.8 available? at least in unofficial packages. Or can they by Dec? I assume that the tar-balls will still get delivered with the ./configure files, so the direct need of autoconf versions may be less important for lots of people just compiling. But it still may break at some point resulting in unexpected behavior - probably during a really important bug-fix release... Yes, the tar-balls will still be delivered as before. Murphys law dictates that such breakage will occur whatever we do ... So I wonder if it is really a wise move to potentially cut off people from security patches because they can no longer compile squid on the system they want to use it on just due to the build-tool dependencies. Is there maybe a plan not to change build-tool versions within a minor version (3.4, 3.5, ...) to somewhat avoid such issues? ... ironically it is security issues which have prompted this change. Our FreeBSD 5 machine was getting too outdated and un-patchable. The biggest toolchain pains over the last few years have been due to our old toolchain versions having incompatibilities compiling on the more up to date OS distributions. Not least of which is 2-digit version numbers and detecting newer available tools. The aim is to make big changes in the toolchains only with beta release testing. For this change it was done in 3.4.4.1 and 3.4.4.2 beta packages last month. Overall we have to face the same version compatibility issues in the toolchain regardless of which versions we distribute with. At least there is a slightly better chance of backward compatility being embeded in the scripts from updated bundled versions than forward-compatibility being embeded by the old. The toolchain upstream have been making some strong efforts in that direction recent years which adds benefit to this change. For those with very large problems the bootstrap.sh script is available in the repository which can regenerate the build scripts against many older version(s) of the toolchain as a last resort. HTH Amos This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
Re: [squid-users] Segment violation in 3.4.5
Unfortunately this report is still short on details.
Could you try to follow the procedure explained in
http://wiki.squid-cache.org/SquidFaq/BugReporting#Using_gdb_debugger_on_Squid
and obtain a backtrace?
Thanks!
On Tue, May 6, 2014 at 3:12 AM, Dan Charlesworth d...@getbusi.com wrote:
Hi folks
We just compiled an EL6 x86_64 RPM for the 3.4.5 update and are now receiving
the Segment violation...dying error for every request.
We're using the same configuration and config options we have been for every
3.4 release so far, with the only change being the addition of
--with-included-ltdl.
We use SSL bump and have a fair few external ACLs so I'm sure there's plenty
of places for it break but this error message isn't very specific. The debug
logs suggest it happens immediately after a transaction is complete:
2014/05/06 10:48:17.771 kid1| Checklist.cc(55) markFinished:
0x7fff494fe6b0 answer ALLOWED for match
FATAL: Received Segment Violation...dying.
Here are our config opts:
%configure \
--exec_prefix=/usr \
--libexecdir=%{_libdir}/squid \
--localstatedir=/var \
--datadir=%{_datadir}/squid \
--sysconfdir=%{_sysconfdir}/squid \
--with-logdir='$(localstatedir)/log/squid' \
--with-pidfile='$(localstatedir)/run/squid.pid' \
--disable-dependency-tracking \
--enable-follow-x-forwarded-for \
--enable-auth \
--enable-auth-basic=DB,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,getpwnam
\
--enable-auth-ntlm=smb_lm,fake \
--enable-auth-digest=file,LDAP,eDirectory \
--enable-auth-negotiate=kerberos,wrapper \
--enable-external-acl-helpers=wbinfo_group,kerberos_ldap_group,AD_group,session
\
--enable-cache-digests \
--enable-cachemgr-hostname=localhost \
--enable-delay-pools \
--enable-epoll \
--enable-icap-client \
--enable-ident-lookups \
%ifnarch ppc64 ia64 x86_64 s390x
--with-large-files \
%endif
--enable-linux-netfilter \
--enable-referer-log \
--enable-removal-policies=heap,lru \
--enable-snmp \
--enable-ssl \
--enable-ssl-crtd \
--enable-storeio=aufs,diskd,ufs \
--enable-useragent-log \
--enable-wccpv2 \
--enable-esi \
--with-aio \
--with-default-user=squid \
--with-filedescriptors=16384 \
--with-maxfd=65535 \
--with-dl \
--with-openssl \
--with-pthreads \
--with-included-ltdl
--
Francesco
Re: [squid-users] Prefetching HTTP GET requests, but under HTTPS
On 6/05/2014 5:53 p.m., Jianshi Huang wrote: Hi, I need to build a prefetching proxy to speedup page loading/clicks and I'm currently investigating Squid for prototype. Websites I want to speedup are all under HTTPS. I briefly scanned Squid's document and google the keywords, looks like I need to do the following setup: 1) Use SSL-Bump (and install Squid's cert in client's machine) Yes this is the only way to get around the HTTPS problem. 2) Two Squid setup, one runs prefetching script, another one does the caching. Any reason for that design? Prefetching only needs three components: The cache (Squid), the logic deciding what to fetch (script), and possibly a database of past info to inform those decisions. Check out the squidclient tool we provide for making arbitrary web requests. It is the best tool around for scripting web requests, similar levels of control to libcurl which is (probably) the best for use in compiled code. Does that make sense? Pre-fetching is a very old idea based around metrics from very old protocols such as HTTP/1.0 where the traffic was static, predictable and prefetching makes a fair bit of sense. However there are several popular features built into HTTP/1.1 protocol which greatly alter that balance. Dynamic content with variants makes it far less static. Response negotiation makes the responses far more unpredictable. Persistent connections greatly reduce the lag times. Revalidation reduces the bandwidth costs. Together these all make prefetching in HTTP/1.1 a much less beneficial operation than most of the literature makes it seem. Whether it makes sense depends entirly on where it is being installed, what the traffic is like, how and why the prefetching decisions are being made. Only you can really answer those and it may actually take doing to figure out whether it was a bad choice to begin with. Is there a better solution? At the current point of Internet development I believe throwing efforts into assisting us with HTTP/2 development would be more beneficial. But I am somewhat biased being a member of the HTTPbis WG and seeking to get Squid HTTP/2 support off the ground. Or has anybody done similar things? We get a fairly regular flow of questions from people wanting to do pre-fetching. They all hit that above issues eventually and drop out of sight. This thread summarizes teh standard problems and answers: http://arstechnica.com/civis/viewtopic.php?f=16t=1204579 (see fandingo's answer near the bottom) I am aware of this tool being used by more than a few dozen installations, although its popularity does seem to be in decline: https://packages.debian.org/unstable/web/squid-prefetch It would be great if someone could point out some configuration/scripting files to me. Code speaks :) Everythig in this regard is situation dependent. The above are likely to be the best you can find. People who actually get it going (apparently anyway) keep the secrets of how to avoid the HTTP/1.1 issues pretty close. HTH Amos
Re: [squid-users] Squid 3.4.5 is available
Em 06/05/14 03:52, Martin Sperl escreveu: I guess People would more likely stay with the older squid version (even if they are buggy) than spending that amount of time and Hassle just to get all the dependencies compiled or even think of upgrading to a new OS version... i'll be one of those ... having LOTS of CentOS 5 machines still running and already migrating them, in no hurry at all, to CentOS 6, i would definitely stick to the last 'compatible' version instead of trying to manually compile libs and compilers or use OS beta versions. -- 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] Fwd: Squid/Ecap Adapter unable to open RAW Socket
Hello, icmp_sock = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP); The above command works fine in squid. But if I run the same command in my eCap adapter I get an error. EPERM (Operation not permitted). Can you please help? Is this related the way dll are handled in linux. Thanks, Jatin
Re: [squid-users] Squid 3.4.5 is available
On 6/05/2014 6:52 p.m., Martin Sperl wrote: C++11 with the requirement for gcc-4.8 would really be a show-stopper for most existing systems... For example RHEL6 still ships with gcc-4.4.7, so a switch there would result in cutting off Centos/RHEL6 as well. Even the Debian I have running on my Raspberry Pi only comes with gcc-4.7.2 as the latest installable option. Only RHEL7beta ships with 4.8 as far as I can tell. And for that to go mainstream one will need to wait at least another year after the official release (which is probably in Q3-2014). This is what we have been waiting for. These last popular distros to have some form of formal release announced that will include the necessary compilers. Their next major series start going public early 2015 by all accounts. Plan is to have C++11 for the Squid series following that late in 2015. So that would definitely reduce possible audience for any squid 3.5 release that makes use of C++11. I know, note the version particular is omitted from the announcement so far. It is probable the version to go stable with this change will actually be 3.6. People will just see 3.HEAD builds as early as the end of the year needing the newer compiler, thus the early announcement. And having people compile gcc and the required dependencies themselves first is another support-nightmare... I guess People would more likely stay with the older squid version (even if they are buggy) than spending that amount of time and Hassle just to get all the dependencies compiled or even think of upgrading to a new OS version... Out of curiosity: which features of c++11 do you want to use to make gcc 4.8 an absolute requirement for the next major release? Atomics for better/simpler SMP and to begin native threading of some components. Lambdas for better hashing, indexing algorithms ACLs etc. Move constructors for better performance across the board. Auto type deduction for simpler APIs on most of the complex template APIs. Each time we go diving into documentation for features we find something else. Some of these like move constructors are already being relied on for performance gains in 3.5 via the increased STL usage. There are other features which we have managed to write custom replacements for 3.3+ (ie nullptr and some of the atomics). However we expect to see small but measurable difference in speed between Squid binaries depending on the compiler version used to build it. Just my 2 cents Martin Thank you. Cheers Amos -Original Message- From: Amos Jeffries On 6/05/2014 2:09 a.m., Martin Sperl wrote: Hi Amos! Does this mean that squid 3.4.4 is no longer supported on RedHat Enterprise/Centos 5 (ships with autoconf 2.59)? RHEL 6 comes with exactly 2.63, so any future update will mean that RHEL6 may also become unsupported as well. That OS version has been best-effort for some months now. We aim to test on the latest stable, previous stable, and if possible and upcoming/rolling release when we can. For CentOS we test on CentOS 6 and 6.5. Just tracking upstream authconf is bound to produce similar pains that I have already experienced with RRDTool on RH3, RH4, RH5 systems. Yes. We are not tracking autoconf upstream itself, but the packaging is now done on a Debian based machine which does have more frequent toolchain updates than our previous FreeBSD 5 machine. On the other hand the C++11 usage is more likely to have an blocking impact on those old RHEL systems. Do they have GCC 4.8 available? at least in unofficial packages. Or can they by Dec? I assume that the tar-balls will still get delivered with the ./configure files, so the direct need of autoconf versions may be less important for lots of people just compiling. But it still may break at some point resulting in unexpected behavior - probably during a really important bug-fix release... Yes, the tar-balls will still be delivered as before. Murphys law dictates that such breakage will occur whatever we do ... So I wonder if it is really a wise move to potentially cut off people from security patches because they can no longer compile squid on the system they want to use it on just due to the build-tool dependencies. Is there maybe a plan not to change build-tool versions within a minor version (3.4, 3.5, ...) to somewhat avoid such issues? ... ironically it is security issues which have prompted this change. Our FreeBSD 5 machine was getting too outdated and un-patchable. The biggest toolchain pains over the last few years have been due to our old toolchain versions having incompatibilities compiling on the more up to date OS distributions. Not least of which is 2-digit version numbers and detecting newer available tools. The aim is to make big changes in the toolchains only with beta release testing. For this change it was done in 3.4.4.1 and 3.4.4.2 beta packages last month. Overall we
Re: [squid-users] Fwd: Squid/Ecap Adapter unable to open RAW Socket
On 6/05/2014 11:16 p.m., Jatin Bhasin wrote: Hello, icmp_sock = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP); The above command works fine in squid. But if I run the same command in my eCap adapter I get an error. EPERM (Operation not permitted). Can you please help? Is this related the way dll are handled in linux. It is related to the application effective user permissions. The Squid helper program which that code is in requires to be run with root user privileges solely in order to do that. Whereas the main Squid binary running your eCAP library is operating under a protected / unprivileged user account when it processes HTTP traffic. Why are you trying to do ICMP from an eCAP adaptor? Amos
Re: [squid-users] Fwd: Squid/Ecap Adapter unable to open RAW Socket
Hello, Thanks for the response. I have to write an application where I have to send icmp pings when I receive certain data in my eCap adapter. But I am stuck at this issue and not able to move forward. I am running squid with cache_effective_user root. What else I would have to do to be able to open socket in my eCap adapter. Thanks, Jatin On Tue, May 6, 2014 at 9:22 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 6/05/2014 11:16 p.m., Jatin Bhasin wrote: Hello, icmp_sock = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP); The above command works fine in squid. But if I run the same command in my eCap adapter I get an error. EPERM (Operation not permitted). Can you please help? Is this related the way dll are handled in linux. It is related to the application effective user permissions. The Squid helper program which that code is in requires to be run with root user privileges solely in order to do that. Whereas the main Squid binary running your eCAP library is operating under a protected / unprivileged user account when it processes HTTP traffic. Why are you trying to do ICMP from an eCAP adaptor? Amos
[squid-users] Squid 3.4.5 crashes when adaptation_access is used
Hello, I have already filed this bug on squid bugzilla. But I have always noticed that responses on mailing list are much faster (almost on same day) and response on bugzilla has taken weeks for me in past! So just bringing this bug in notice. http://bugs.squid-cache.org/show_bug.cgi?id=4057 Summary is, I have this line in squid.conf adaptation_access service_avi allow !novirusscan (scan for viruses if site is not list in novirusscan) On squid 3.4.4.2 this works perfect but squid 3.4.5 crashes. If I remove that line then squid 3.4.5 works fine but then I lose virus scanning. Please see bug report for details. Thanks and regards, Amm.
Re: [squid-users] Fwd: Squid/Ecap Adapter unable to open RAW Socket
Thanks I was able to solve this issue by setting up effective user permissions. On Tue, May 6, 2014 at 9:22 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 6/05/2014 11:16 p.m., Jatin Bhasin wrote: Hello, icmp_sock = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP); The above command works fine in squid. But if I run the same command in my eCap adapter I get an error. EPERM (Operation not permitted). Can you please help? Is this related the way dll are handled in linux. It is related to the application effective user permissions. The Squid helper program which that code is in requires to be run with root user privileges solely in order to do that. Whereas the main Squid binary running your eCAP library is operating under a protected / unprivileged user account when it processes HTTP traffic. Why are you trying to do ICMP from an eCAP adaptor? Amos
Re: [squid-users] Squid 3.4.5 is available
On 6/05/2014 4:07 a.m., Amm wrote: Squid is very widely used software and this move may break lots of things for many administrators. Please note that we have already had several distributors using old versions of the popular OS to successfully build the updated 3.4 packages and confirm that there were no problems doing so. This was a basic criteria for doing it at all. Security updates are, and will continue to be, distributed in patches that can be applied on older releases without upgrading the whole of Squid. These changes only have any *potential* affect for administrators attempting to build the latest Squids' on very old systems outside the relevant official OS distributors support channels. autoconf, automake, gcc may depend on other softwares and so even those other softwares may also require update. Updating those softwares may also break other softwares which depend on older versions. So its going to be huge task for administrator. As you say this is true of any software being back-ported to a vendors LTE disribution. Squid is no exception. This announcement is just a notification that the bar is being moved slightly from 6 years ago. PS. minimum version of autoconf has actually already been 2.63 for that entire time without anyone noticing. I am also surprised that this change (a major one in my opinion) was made in minor-minor release. As Martin suggested may be this change should be pushed to Squid 4.x major version. So please consider the request. Considered. Unfortunately we have to balance a known guarantee of build failure on several newly released OS - which will affect Squid ability to be used there over the coming years as those systems gain popularity, against a risk that the group of administrators choosing to stick with very old systems (declining in size over time) will have some trouble. Also many features current Squid offer over older versions are grounded in the OS on which it is built and/or runs. The benefits of the latest kernel CPU optimizations, SMP support, or relying on current libc performance are non-existent when built and run on a 5+ year old system. Amos Thanks and regards, Amm. On 05/05/2014 07:39 PM, Martin Sperl wrote: Hi Amos! ... So I wonder if it is really a wise move to potentially cut off people from security patches because they can no longer compile squid on the system they want to use it on just due to the build-tool dependencies. Is there maybe a plan not to change build-tool versions within a minor version (3.4, 3.5, ...) to somewhat avoid such issues? Thanks, Martin
Re: [squid-users] Requiring C++11 support (Was: Squid 3.4.5 is available)
On 05/06/2014 12:52 AM, Martin Sperl wrote: Out of curiosity: which features of c++11 do you want to use to make gcc 4.8 an absolute requirement for the next major release? IMO, none. As Amos have mentioned, C++11 offers a few development convenience/safety features and some performance improvements, but none of them are an absolute requirement for the next major release. FWIW, I was also surprised by the approaching C++11 requirement announcement. This is not my area of expertise, but I consider compiler requirements different from autoconf requirements that were also discussed on this thread. When it comes to autoconf, bootstrapping folks running on older machines (e.g., RHEL5) have a few acceptable options. For example, it is not very difficult to install the right autoconf/etc versions from sources locally and bootstrap Squid using them (in a user account on the same RHEL5 machine or elsewhere). This is annoying, but does not affect many admins, does not affect overall system operation, does not introduce a lot of unknowns, and does not conflict with most local policies. Installing a custom compiler version or cross-compiling is a much bigger problem on many levels IMHO. Cheers, Alex. On 05/06/2014 05:17 AM, Amos Jeffries wrote: Atomics for better/simpler SMP and to begin native threading of some components. Lambdas for better hashing, indexing algorithms ACLs etc. Move constructors for better performance across the board. Auto type deduction for simpler APIs on most of the complex template APIs. Each time we go diving into documentation for features we find something else. Some of these like move constructors are already being relied on for performance gains in 3.5 via the increased STL usage. There are other features which we have managed to write custom replacements for 3.3+ (ie nullptr and some of the atomics). However we expect to see small but measurable difference in speed between Squid binaries depending on the compiler version used to build it.
Re: [squid-users] feature requests
On 04/29/2014 02:20 AM, Amos Jeffries wrote: perfecting the COSS caching model into the one now called rock to load multiple objects in single fast disk loads Please note that Rock does not use the COSS caching model, does not try to perfect it, and does not load multiple objects in single fast disk read. Like with any two storage systems, the are some similarities between COSS and Rock (e.g., both use a single file per cache_dir), but the two should be viewed as completely different storage models. Thank you, Alex.
[squid-users] Re: Delay Pools
Please, anyone? -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Delay-Pools-tp4665836p4665853.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Re: Squid 3.3.8 does not work with mobile app
On 05/05/2014 10:38 AM, 0bj3ct wrote: I have a transparent Squid. But no one mobile app works with it. More details will be the basic answer: What is the IP topology of the network? What rules have you used in IPTALBES? is it a new machine? have you considered using 14.04? Eliezer
Re: [squid-users] url_rewrite_program receives empty lines as input
Hey there,
I will try my Mind-reading technique on you if you are fine with it:
You are using squid 3.4.X??
(just wondering)
When the helper gets empty lines it means that it probably ended it's
life-cycle and it's recommended to do a clean exit of the helper.(from
my experience).
in what language is thie url_rewrite helper written?
Eliezer
On 05/05/2014 10:34 AM, Javier Amor Garcia wrote:
Hello,
I have a problem with the url_rewrite_program, sometimes it receives a
blank line as input. Normally, it works fine but when begins to receive
empty lines, it receives them continually. I don't know what triggers it.
The rewrite script is like this:
while (1) {
my $line = ;
... process and return ..
}
I can see the empty lines debugging just after the assignation of the
read line to the line variable.
The configuration of the squid is a bit complicate, I have two squid
sandwiching a dansguardian. The url_rewrite_program is in the internal
squid. I have not seen this problem when I remove dansguardian but it
maybe just by chance.
Regards,
Javier
Re: [squid-users] Skype SSL is incompatible with OpenSSL
Hi Marcus and Amos, Thank you for the clarification. In my case that I am using fake connect (interception proxy), there must be a way on how to exclude skype on SSL Bumping. I tried to exclude browser ^skypeuser agent as discussed with squid wiki and still doesn't work. Also, I tried to exclude almost all sites on SSL bump and Skype still can't connect. As I said earlier my firewall blocks everything except web (80 443) , dns. My firewall is also intercepting 443 and 80 via wccp 70 and web-cache redirect by Cisco that's why Skype will always be intercepted by Squid. I'm wondering if there's someone who successfully allowed Skype to fake CONNECT to squid (I'm referring to interception not explicit proxying). I cannot fully implement https interception until I find a solution to properly intercept Skype. Many thanks in advance for all the help. Jay On Sat, May 3, 2014 at 3:02 AM, Marcus Kool marcus.k...@urlfilterdb.com wrote: On 05/02/2014 08:21 AM, Jay Jimenez wrote: Hi Amos, Thank you for the response. Any advice of how would I know exactly what SSL/TLS version skype is using and how do I enable those versions to my squid box? It has been a while since I investigated Skype but my findings at that time were that Skype does not use SSL. Instead, it does a CONNECT and wants a tunnel through Squid but the SSL bumping only works if the web servers talk SSL+HTTP (HTTPS). In short, SSL bumping does not work for Skype. Marcus What are changes in 3.4.5 in terms of ssl bumping? Would it help me on my existing transparent setup to resolve my skype issue? Thanks, Jay On Fri, May 2, 2014 at 6:57 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 2/05/2014 10:34 p.m., Jay Jimenez wrote: Hi, I have squid setup that is currently doing transparent SSL interception. Almost all websites work flawlessly like https://facebook.com, gmail, banking websites etc. However, when intercepting SKYPE I've got the following error on my cache.log 2014/05/02 18:18:11 kid1| clientNegotiateSSL: Error negotiating SSL connection on FD 166: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number (1/-1) 2014/05/02 18:18:16 kid1| clientNegotiateSSL: Error negotiating SSL connection on FD 155: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number (1/-1) 2014/05/02 18:18:16 kid1| clientNegotiateSSL: Error negotiating SSL connection on FD 26: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number (1/-1) This means the SSL/TLS version being requested by the client is not supported by your proxy. For example; if Skype requires one of SSL/1.0, SSL/2.0 or SSL/3.0 and your proxy or OpenSSL library is configured to disable those insecure versions. NP: It is becomming common for TLS/1.1 or TLS/1.2 to be the only supported versions in software as the older protocols are vulnerable to the BEAST and CRIME attacks. FYI: 3.4.5 comes out in a few hours. It has an update to CONNECT which also may be involved with this. 2014/05/02 18:18:21 kid1| clientNegotiateSSL: Error negotiating SSL connection on FD 34: error:1408F10B:SSL My Setup: Our firewall only allows ports 80 and 443 and some business ports that's why Skype will always be redirected by our WCCP router to the squid box. My openssl version is OpenSSL 1.0.1e 11 Feb 2013 I hope you have patched that for the Heartbeat vulnerability. NOTE: Squid is not particularly suceptible to Heartbeat due to our memory pooling feature but there is still some leakage and other software on the machine will be vulnerable. My squid version is 3.4. I also tried different Squid versions but failed. Amos
Re: [squid-users] Delay Pools
On Tue, May 6, 2014 at 3:38 AM, tomaswaldow to...@waldow.ws wrote: Hi I have a problem in Squid 3.1.20 with Debian 7. The settings of the delay pools are as follows: delay_pools 1 1 2 delay_class delay_parameters 1 -1/-1 10/10 1 delay_access allow localnet! CONNECT Should be limited to 100KB but does not work. Is ranging between 50 to 55. Try this: delay_pools 1 delay_class 1 3 delay_parameters 1 -1/-1 -1/-1 10/10 delay_access 1 allow...
