diff --git a/RELEASENOTES.html b/RELEASENOTES.html index e2fade6..70b3db1 100644 --- a/RELEASENOTES.html +++ b/RELEASENOTES.html @@ -2,14 +2,14 @@ - Squid 3.2.13 release notes + Squid 3.3.8 release notes -

Squid 3.2.13 release notes

+

Squid 3.3.8 release notes

Squid Developers


-This document contains the release notes for version 3.2 of Squid. +This document contains the release notes for version 3.3 of Squid. Squid is a WWW Cache application developed by the National Laboratory for Applied Network Research and members of the Web Caching community.
@@ -18,28 +18,20 @@ for Applied Network Research and members of the Web Caching community.

-

2. Major new features since Squid-3.1

+

2. Major new features since Squid-3.2

-

3. Changes to squid.conf since Squid-3.1

+

3. Changes to squid.conf since Squid-3.2

-

4. Changes to ./configure options since Squid-3.1

+

4. Changes to ./configure options since Squid-3.2

-

5. Options Removed since Squid-2

+

5. Regressions since Squid-2.7

-

-

6. Regressions since Squid-2.7

- -

1. Notice

-

The Squid Team are pleased to announce the release of Squid-3.2.13.

+

The Squid Team are pleased to announce the release of Squid-3.3.8.

This new release is available for download from -http://www.squid-cache.org/Versions/v3/3.2/ or the +http://www.squid-cache.org/Versions/v3/3.3/ or the mirrors.

-

A large number of the show-stopper bugs have been fixed along with general improvements to the IPv6 support. +

A large number of the design flaws in SSL-Bump feature have been fixed along with general improvements all around. While this release is not fully bug-free we believe it is ready for use in production on many systems.

We welcome feedback and bug reports. If you find a bug, please see -http://wiki.squid-cache.org/SquidFaq/BugReporting for how to submit a -report with a stack trace.

+http://wiki.squid-cache.org/SquidFaq/BugReporting +for how to submit a report with a stack trace.

1.1 Known issues

Although this release is deemed good enough for use in many setups, please note the existence of -open bugs against Squid-3.2.

- -

Some issues to note as currently known in this release which are not able to be fixed in the 3.2 series are:

-

-

-

- -

Currently known issues which only depends on available developer time and may still be resolved in a future 3.2 release are:

-

-

-

+open bugs against Squid-3.3.

-

1.2 Changes since earlier releases of Squid-3.2 +

1.2 Changes since earlier releases of Squid-3.3

-

The 3.2 change history can be -viewed here.

+

The 3.3 change history can be +viewed here.

-

2. Major new features since Squid-3.1

+

2. Major new features since Squid-3.2

-

Squid 3.2 represents a new feature release above 3.1.

+

Squid 3.3 represents a new feature release above 3.2.

The most important of these new features are:

Most user-facing changes are reflected in squid.conf (see below).

- -

2.1 CVE-2009-0801 : NAT interception vulnerability to malicious clients. +

2.1 SQL Database logging helper

-

Details in Advisory -SQUID-2011:1

+

log_db_daemon - Database logging daemon for Squid

-

Squid locates the authority-URL details available in an HTTP request as -defined by RFC 2616 and validates that all found representations are -textually equivalent. In the case of intercepted traffic the -client destination IP is also compared to the Host: authority domains -DNS entries.

+

This program writes Squid access.log entries to an SQL database. +Written in Perl it can utilize any database supported by the Perl +database abstraction layer.

-

When the Host: authority contradicts another authority source Squid will log -"SECURITY ALERT: Host: header forgery detected". The response will then be determined -by the -host_verify_strict -directive. Squid will respond with 409 Conflict error response when strict validation -fails and handles the request normally when strict validation succeeds or is OFF (default).

- -

Relaying of messages which FAIL non-strict Host: validation are permitted through Squid but -only to the original destination IP the client was requesting or to explicit peers. This means -DNS lookups to locate alternative DIRECT destinations will not be done.

- -

Known Issue: When non-strict validation fails Squid will relay the request, but can only do -so safely to the original destination IP the client was contacting. The client original -destination IP is lost when relaying to peers in a hierarchy. This means the upstream peers -are still at risk of causing same-origin bypass CVE-2009-0801 vulnerability. -Developer time is required to implement safe transit of these requests. -Please contact squid-dev if you are able to assist or sponsor the development.

+

NOTE: Presently it only accepts the Squid native log format.

-

2.2 NCSA helper DES algorithm password limits +

2.2 Time-Quota session helper

-

Details in Advisory -SQUID-2011:2

+

ext_time_quota_acl - Time quota external ACL helper.

-

The DES algorithm used by the NCSA Basic authentication helper has an -limit of 8 bytes but some implementations do not error when truncating -longer passwords down to this unsafe level.

+

Allows an administrator to define time budgets (quota) for the +users of Squid to limit the time using Squid.

-

This both significantly lowers the threshold of difficulty decrypting -captured password files and hides from users the fact that the extra bits -of their chosen long password is not being utilized.

+

This is useful for corporate lunch time allocations, wifi portal +pay-per-minute installations or for parental control of children.

-

The NCSA helper bundled with Squid will prevent passwords longer than 8 -characters being sent to the DES algorithm. The MD5 hash algorithm which -supports longer than 8 character passwords is also supported by this helper -and should be used instead.

+

The administrator can define a time budget (e.g. 1 hour per day) +which is enforced through this helper using session estimations +of their browsing time. A 'pause' threshold is given in seconds +and defines the period between two requests to be treated as part +of the same session. Pauses shorter than this value will be +counted against the quota, longer ones ignored.

-

2.3 SMP scalability +

2.3 SSL-Bump Server First

-

The new "workers" squid.conf option can be used to launch multiple worker -processes and utilize multiple CPU cores. The overall intent is to make -multiple workers look like one to an outside observer, while providing -knobs to customize each worker behavior if needed.

+

Details at +http://wiki.squid-cache.org/Features/BumpSslServerFirst.

-

By default, all worker processes are configured identically and do what a -single Squid instance would have done. Squid.conf macro substitutions and -conditionals (see below) can be used to customize individual worker -configurations. In the paragraphs below, "can share" implies "will share by -default".

- -

Workers can share HTTP, HTTPS, SNMP, ICP, and HTCP listening addresses. -Configuration related to ICP and HTCP clients must be adjusted to avoid -source address conflicts: Modify the IP address and/or the port used for -the protocol. Workers do not share DNS addresses by default because the OS -assigns each worker a unique DNS port.

- -

Workers can share logs.

- -

Workers can share caches. Memory cache is automatically shared when multiple -workers are used. Cache_dir are shared when configured with the rock -storage type. Cache_dir of other types must be adjusted to point each -disk-caching worker to its own disk area. ICP and HTCP responses are based -on the responding worker cache state.

- -

Cache manager statistics are reported from a worker point of view, for now. -Though some reports are combined. SNMP statistics are combined across all -workers.

- -

Startup, reconfiguration, shutdown, and log rotation are handled as for a -monolithic Squid. Abnormally terminated workers are restarted while -other workers continue serving traffic.

- -

Squid.conf macros and conditionals

- -

Added support for process_name and process_number macros as well as simple -if-statement conditionals in squid.conf. These features allow individual -worker customization in SMP mode. For details, search for "Conditional -configuration" and "SMP-Related Macros" sections in squid.conf.documented.

- - -

2.4 Helper Multiplexer -

- -

The helper multiplexer's purpose is to relieve some of the burden -Squid has when dealing with slow helpers. It does so by acting as a -middleman between squid and the actual helpers, talking to Squid via -the multiplexed concurrent variant of the helper protocol and to the -helpers via the non-concurrent variant.

- -

Helpers are started on demand, and in theory the muxer can handle up to -1k helpers per instance. It's up to squid to decide how many helpers -to start.

- -

The muxer knows nothing about the actual messages being passed around, -and as such can't really (yet?) compensate for broken helpers. -It is not yet able to manage dying helpers, but it will.

- -

To configure the multiplexer add its binary name (usually /usr/share/libexec/helper-mux.pl) -in front of the name of whichever helper is being multiplexed. It takes the helper binary -path and parameters as its own command parameters. The concurrency setting already -existing in Squid is used to configure how many child helpers it may run.

- -

For example, a traditional configuration is -

-        url_rewrite_program /your/redirector.sh
-        url_rewrite_children 5
-   
-
- -the alternative multiplexer configuration is: -
-        url_rewrite_program /usr/share/libexec/helper-mux.pl /your/redirector.sh
-        url_rewrite_children 1 concurrency=5
-   
-
-

- -

Helpers which are already concurrent protocol enabled gain little benefit from the multiplexer -on most systems. However on some systems where Squid spawning helpers causes excess memory usage -the reduction in direct helper spawned by Squid can result in a great reduction in resource use.

- -

The helper can be controlled using various signals: -

-

- - -

2.5 Helpers On-Demand -

- -

Traditionally Squid has been configured with a fixed number of helpers and started them during -it's start and reconfigure phases. This forces the hard configuration problem of how many helpers -will be needed to be solved before starting Squid in production use.

- -

The on-demand helpers feature allows greater flexibility and resolves this problem by allowing -maximum, initial and idle thresholds to be configured. Squid will start the initial set during -start and reconfigure phases. However over the operational use new helpers up to the maxium will -be started as load demands. The idle threshold determines how many more helpers to start if the -currently running set is not enough to handle current request loads.

- -

For example, a traditional configuration is -

-        auth_param ntlm /usr/libexec/squid/ntlm_auth
-        auth_param ntlm children 200
-   
-
- -the alternative on-demand configuration could be: -
-        auth_param ntlm /usr/libexec/squid/ntlm_auth
-        auth_param ntlm children 200 startup=10 idle=2
-   
-
-

- -

The example still permits up to 200 helpers to be running at once under peak traffic loads. -But only starts 10 when Squid is initialized resulting in a faster boot up. -When client requests threaten to overload the running helpers an additional 2 will be started.

- -

NOTE: if no startup and idle values are specified the traditional behaviour -of starting the maximum number of helpers will occur.

- - -

2.6 Helper Name Changes -

- -

To improve the understanding of what each helper does and where it should be used the helper binaries -which are bundled with Squid have undergone a naming change in this release.

- -

Below is a list of the old helper names and what their names have changed to. -For several helpers the directory name used in --enable-X-helpers configure option has also changed.

- -

Basic Authentication protocol helpers

+

When an intercepted connection is received, Squid first connects +to the server using SSL and receives the server certificate. +Squid then uses the host name inside the true server certificate +to generate a fake one and impersonates the server while still +using the already established secure connection to the server.

+

Bumping server first is essentially required for handling +intercepted HTTPS connections but the same scheme should be used +for most HTTP CONNECT requests because it offers a few advantages +compared to the old bump-client-first approach:

-

Digest Authentication protocol helpers

- -

-

-

- -

External ACL helpers

- -

-

-

- -

Negotiate Authentication protocol helpers

- -

-

-

- -

NTLM Authentication protocol helpers

- -

-

-

- -

URL re-write helpers

- -

This group of helpers have been bundled to demonstrate how to code URL re-writers: -

-

- - -

2.7 Multi-Lingual manuals +

2.4 Server Certificate Mimic

-

The man(8) and man(1) pages bundled with Squid are now provided online for all -versions and beginning with 3.2 they are available in languages other than English (where translated).

+

Details at +http://wiki.squid-cache.org/Features/MimicSslServerCert.

-

Details in -The Squid wiki

- -

3.1 began the Internationalization of Squid with the public facing error pages. -This move begins the Localization of the internal administrator facing manuals.

+

One of the SslBump features serious drawbacks is the loss of +information embedded in SSL server certificate. +This certificate mimic feature passes original SSL server +certificate information to the user. Allowing the user to +make an informed decision on whether to trust the server +certificate.

-

2.8 Solaris 10 pthreads Support (Experimental) +

2.5 Custom HTTP request headers

-

Automatic detection and use of the pthreads library available from Solaris 10

+

The request_header_add option is added to insert +HTTP header fields to outgoing HTTP requests (i.e., +request headers sent by Squid to the next HTTP hop such as a +cache peer or an origin server). The option has no effect on +cache hit traffic or requests serviced by Squid and ICAP.

-

The result of this addition means that faster more efficient AUFS cache storage mechanism -is now available in Solaris 10.

+

WARNING: If a standard HTTP header name is used, Squid does not check whether +the new header conflicts with any existing headers or violates +HTTP rules. If the request to be modified already contains a +field with the same name, the old field is preserved but the +header field values are not merged.

-

Support is experimental at this stage due to lack of feedback on the results of enabling it. -We recommend giving AUFS a try for faster disk storage and encourage feedback.

+

Field-value set can be either a token or a quoted string. If quoted +string format is used, then the surrounding quotes are removed +while escape sequences and %macros are processed.

+ +

In theory, all of the logformat codes can be used as %macros. +However, unlike logging (which happens at the very end of +transaction lifetime), the transaction may not yet have enough +information to expand a macro when the new header value is needed. +And some information may already be available to Squid but not yet +committed where the macro expansion code can access it (please report +such instances!). The macro will be expanded into a single dash +('-') in such cases. Not all macros have been tested.

+ +

One or more Squid ACLs may be specified to restrict header +injection to matching requests. As always in squid.conf, all +ACLs in an option ACL list must be satisfied for the insertion +to happen. The request_header_add option supports fast ACLs only.

-

2.9 Surrogate/1.0 protocol extensions to HTTP -

+

3. Changes to squid.conf since Squid-3.2

-

The Surrogate extensions to HTTP protocol enable an origin web server to specify separate -cache controls for a reverse proxy acting on its behalf. Previously this was closely tied with the ESI -feature support in Squid. This release opens Surrogate support to all reverse proxies.

- -

Reverse proxy requests sent on to the web server include the HTTP header Surrogate-Capabilities: -specifying the capabilities of the reverse proxy along with an ID which can be used to target responses with -a Surrogate-Control: HTTP header used instead of the Cache-Control: header.

- -

The default surrogate ID is generated automatically from the Squid site-unique hostname as found by the -automatic detection or manual configuration of visible_hostname although can be configured -separately with the httpd_accel_surrogate_id option.

- -

Security Considerations: Websites should be careful of accepting any surrogate ID. -Older releases of Squid leak the Surrogate-Control headers to external servers. -This 3.2 series of Squid will now prevent this leakage of its own ID destined responses, however it is possible -and for some uses desirable to receive external reverse-proxies Surrogate-Capabilities: headers.

- -

NOTE: Several operating system distributions historically package Squid with a forced value of -visible_hostname localhost. If this is done on a Surrogate enabled install a manual re-configuration -is required to prevent an unacceptable surrogate ID of 'localhost' being generated.

- - -

2.10 Logging Infrastructure Updated -

- -

The advanced logging modules introduced in Squid-2.7 are now available from Squid-3.2.

- -

This feature is documented at http://wiki.squid-cache.org/Features/LogModules

- -

The new infrastructure currently supports several different channels types (modules) ranging from -direct filesystem logging (stdio, daemon) to network logging (syslog, UDP and TCP). The daemon logging -interface allows for a custom helper to be written to process logs in real-time.

- -

Upgrading: the access_log and cache_store_log were previously logged via what is -now called the stdio module. -This is still supported and used by default if no module is named. For best performance particularly in SMP -environments we recommend the daemon be used. The provided log_file_daemon helper -performs the traditional logging to local filesystem.

- -

Additional to this the cache.log can now be limited to a smaller number of files stored. -Traditionally cache.log.N has been fixed at the same number of rotated files as access.log.N through the -logfile_rotate setting. The debug_options setting can now be used to configure the number -of debug cache.log files to rotate through with a rotate=N option. This is particularly useful for -logging a single cache.log at relatively high debug levels on a high-traffic system. Or one which is -required to store a long period of access.log and needs to conserve disk space.

- -

The referer_log and useragent_log directives have been converted to built-in log formats. -These logs are now created using an access_log line with the format "referrer" or "useragent". -They also now log all client requests, if there was no Referer or User-Agent header a dash (-) is logged.

- -

Known Issue: The TCP logging module does not recover from broken connections well. -At present it will restart the affected Squid instance if the TCP connection is broken.

- - -

2.11 Client Bandwidth Limits -

- -

In mobile environments, Squid may need to limit Squid-to-client bandwidth -available to individual users, identified by their IP addresses. The IP -address pool can be as large as a /10 IPv4 network (4 million unique IP -addresses) and even larger in IPv6 environments. On the other hand, the code -should support thousands of connections coming from a single IP (e.g., -a child proxy).

- -

The implementation is based on storing bandwidth-related "bucket" information -in the existing "client database" hash (client_db.cc). The old code already -assigned each client IP a single ClientInfo object, which satisfies the -client-side IP-based bandwidth pooling requirements. The old hash size is -increased to support up to 32K concurrent clients if needed.

- -

Client-side pools are configured similarly to server-side ones, but there is -only one pool class. See client_delay_pools, -client_delay_initial_bucket_level, client_delay_parameters, and -client_delay_access in squid.conf. The client_delay_access matches the client -with delay parameters. It does not pool clients from different IP addresses -together.

- -

Special care is taken to provide fair distribution of bandwidth among clients -sharing the same bucket (i.e., clients coming from the same IP address). -Multiple same-IP clients competing for bandwidth are queued using FIFO -algorithm. If a bucket becomes empty, the first client among those sharing -the bucket is delayed by 1 second before it can attempt to receive more -response data from Squid. This delay may need to be lowered in -high-bandwidth environments.

- - -

2.12 Better eCAP Suport -

- -

Support for libecap version 0.2.0 has been added with this series of Squid. Bringing -better support for body handling, and logging.

- -

Known Issue: Due to API changes in libecap this release of Squid will not build -against any older libecap releases.

- - -

2.13 Cache Manager access changes -

- -

The Squid Cache Manager has previously only been accessible under the cache_object:// -URL scheme. Which has restricted its reporting to tools which can send arbitrary -URI to the proxy.

- -

This version of Squid now provides access through the http:// and https:// URL schemes -allowing web browsers access without having to use the cachemgr.cgi gateway and enabling -the use of HTTPS security were desired.

- -

The cache manager is available under the path prefix /squid-internal-mgr/. For example -the URL http://example/com/squid-internal-mgr/menu will bring up the manager menu. This -means there are some configuration changes required to lock down manager access. -The manager ACL needs changing. A built-in definition is now used, equivalent -to the following regex pattern: -

-        ^(cache_object://|https?://[^/]+/squid-internal-mgr/)
-
-

- -

The manager prefix /squid-internal-mgr/ with no action attempts to load an optional -template MGR_INDEX which may be installed amongst in the Squid error templates. -This template is not supplied with Squid but intended to be supplied by separate -cache manager applications as their front page embedding all scripts, accessors or -redirects required for their initial GUI display.

- -

MGR_INDEX file -

-

- -

Version 3.2 of the CGI cache manager tool now presents XHR scripted probes to detect -proxies presenting these manager index pagess and provides direct HTTP/HTTPS web links -to those managers.

- - -

3. Changes to squid.conf since Squid-3.1

- -

There have been changes to Squid's configuration file since Squid-3.1.

+

There have been changes to Squid's configuration file since Squid-3.2.

This section gives a thorough account of those changes in three categories: