Re: lib/cppunit-1.10.0/bootstrap.sh missing in squid-HEAD.snapshot
On Wed, 27 Jul 2005, Gonzalo Arana wrote: Hi, The file lib/cppunit-1.10.0/bootstrap.sh is missing in squid3-HEAD snapshot (downloaded from http://www.squid-cache.org/Versions/v3/HEAD/squid-HEAD.snapshot.tar.bz2), but is present in cvs repository (cvs.squid-cache.org:/squid). This causes an error when trying to run bootstrap.sh. There are other differences as well, but only this one seems signifficant (at least for me). Not entirely sure we should have the bootstrap.sh script at all in the distributed sources. Regards Henrik
Re: use of iptables for transparent squid
This question belongs on squid-users, not squid-dev. Moving the discussion there. On Mon, 1 Aug 2005, mohinder garg wrote: I am trying to run squid in transparent mode. it works fine using the iptables but i want to run it without using iptables...is there any other way to run it in transparent modebecouse the system that i m trying to build does not has iptables support. This is mainly a host OS question, not a Squid question. You need some method of making your host OS accept the TCP/IP sessions and send them to Squid as if the requests were sent to the Squid port on the host. iptables or other NAT function can do this quite fine. The limitation is that if you NAT on another device or by means not supported by Squid then HTTP/1.0 requests without the Host header won't work. Nearly all HTTP clients sends the Host header these days so that's rarely a problem. In such configuration set httpd_accel_host to your main web site (not virtual). But there is no means whereby Squid would make your host OS intercept traffic without having this support in the host OS or nearby NAT device/firewall. Regards Henrik
Re: whitepaper on HTTP request smuggling
On Thu, 28 Jul 2005, Andrey Shorin wrote: Hello Squid, In case somebody didn't read it yet... http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf Russian translation available: http://apachedev.ru/modules.php?name=Pages&go=page&pid=19 As some of you know and as can be seen on page 21 it's the trigger which started the noticeable HTTP hardening in the recent 2.5 versions.. I'll update the advisory with a link to the published paper in the credits section. It's a quite manageabe problem and to my best knowledge we and any parents to us are fully safe from this after the patches, but child caches may be at risk.. A more interesting problem to ponder about is the response splitting problem.. (see the first reference for details). Squid does go to a great extent for detecting this when possible, but if you have a vulnerable parent quite bad things may result with server-side persistent connections is enabled.. Regards Henrik
Re: Squid 3 build problem on RedHat Enterprise Linux 3 update 4
On Fri, 15 Jul 2005, Andrey Shorin wrote: ../include/Array.h: In member function `Vector& Vector::operator+=(E)': ../include/Array.h:95: warning: no return statement in function returning non-void Thanks for your patch. It has been merged. Regards Henrik
Re: Need help with dns_query patch
On Wed, 13 Jul 2005, Luigi Gangitano wrote: Hi, I packaged an update squid 2.4.STABLE6 for Debian woody with the backported squid-2.5.STABLE9-dns_query from RedHat RHSA-2005-489, which is quite straight. With this patch squid fails[1] with rfc1035.c:410: rfc1035RRUnpack: Assertion `(*off) <= sz' failed which can be reproduced accessing http://62.26.121.2:80/dat/bgf/trpix.gif This seems to happen on SuSE squid-2.5.STABLE1[2] too. I cannot understand the RFC1035 code enough to debug it, can you please help? The interactions between lib/rfc1035.c and src/dns_internal.c has changed many times to address issues with decoding of malformed packets. The following list of patches is relevant: squid-2.5.STABLE2-dns_root_label.patch squid-2.5.STABLE5-rfc1035NameUnpack.patch squid-2.5.STABLE7-fqdn_truncated.patch squid-2.5.STABLE9-dns_query-5.patch Also as can be seen in the list the dns_query patch was updated many times after the initial release so you'd better make sure it is the current revision you are backporting. Regards Henrik
Re: Opinion on some open bugs
On Tue, 12 Jul 2005, Serassio Guido wrote: The problem is clear. But what about a simple workaround like the following patch ? +#ifdef _SQUID_SOLARIS_ +#define SOLARIS 1 +#undef free +#undef sync +#endif #include Looks reasonable as a temporary workaround, but the real problem of in which order the include files are referenced should be fixed. For now add a comment just why this is required and I am fine with it. Regards Henrik
Re: Chained + unchained SSL cert patch
On Mon, 25 Jul 2005, Travis Lansdell wrote:
The problem I had with the Squid-provided patch is that I couldn't use
both chained and regular SSL certificates simultaneously
I have no problems here to mix chained and unchanied certificates freely
with the SSL update to 2.5. I most frequenly use a number of unchained
certificates, but occationally there is a couple of chained certificates
in the mix and no problems have been observed for a very long time.
-if (!SSL_CTX_use_certificate_file(sslContext, certfile,
SSL_FILETYPE_PEM)) {
- ssl_error = ERR_get_error();
- fatalf("Failed to acquire SSL certificate: %s\n",
- ERR_error_string(ssl_error, NULL));
+if (!SSL_CTX_use_certificate_chain_file(sslContext, certfile)) {
+ if (!SSL_CTX_use_certificate_file(sslContext, certfile,
SSL_FILETYPE_PEM)) {
+ ssl_error = ERR_get_error();
+ fatalf("Failed to acquire SSL certificate: %s\n",
+ ERR_error_string(ssl_error, NULL));
+ }
The inner SSL_CTX_use_certificate_file call here is redundant as
SSL_CTX_use_certificate_chain_file also loads unchained certificates. If
SSL_CTX_use_certificate_chain_file fails then SSL_CTX_use_certificate_file
will fail as well. At least according to documentation and my experience
of these functions and the OpenSSL error stack.
Some time ago an unrelated OpenSSL problem was discovered relating to CA
certificates which would cause loading of the next certificate to always
fail in some situations involving the clientca option. Maybe you were
bitten by this?
The SSL code in 2.5 is known to be quite broken in several aspects, not
just the lack of support for chained certificates. There is also issues
with handling of largeish SSL segments in POSTs etc and a number of other
problems addressed by the SSL update, several of which requiring quite
significant reworkings of how the SSL I/O operations is scheduled. For
this reason I have selected to not touch the code for the duration of 2.5
and instead refer to the SSL update for people needing more advanced SSL
functionality.
Regards
Henrik
