Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 10 Jul 2015 15:33:28 +1200
From: Amos Jeffries <>
Subject: Re: Squid HTTP proxy CVE request

Hash: SHA1

On 10/07/2015 8:47 a.m., Reed Black wrote:
> As I read this, issue #1 allows CONNECT requests to proceed that
> shouldn't otherwise. Is unsetting AllowTcpForwarding also
> sufficient for the "Determining if your version is vulnerable"
> section?

Short answer is no.

Lonng answer:

Since the only reference I can find for AllowTcpForwarding is TLS/SSL
related it looks like you are falling into the common misbelief that
HTTP CONNECT messages mean HTTPS (TLS).

CONNECT is a generic instruction for the proxy to setup a TCP tunnel.
Once such a tunnel exists it can be used for any TCP based protocol.
HTTP over TLS is just one usage

So no, the breakage happens at the plain-text HTTP layer below any TLS
that might be used to secure whatever the tunnelled protocol is.


> On Mon, Jul 6, 2015 at 4:26 AM, Amos Jeffries
> <> wrote:
> Greetings,
> This months release of Squid HTTP proxy, version 3.5.6, contains
> fixes for two security issues.
> Issue #1:
> Due to incorrect handling of peer responses in a hierarchy of 2 or 
> more proxies remote clients (or scripts run on a client) are able
> to gain unrestricted access through a gateway proxy to its backend
> proxy.
> If the two proxies have differing levels of security this could
> lead to authentication bypass or unprivileged access to supposedly
> secure resources.
> <
> All Squid up to and including 3.5.5 are vulnerable.
> (when published the advisory for this will be 
> <>)
> Issue #2:
> This is somewhat more obscure, and I am seeking clarification
> perhapse more than assignment.
> Squid up to and including 3.5.5 are apparently vulnerable to DoS 
> attack from malicious clients using repeated TLS renegotiation 
> messages. This has not been verified as it also seems to require 
> outdated (0.9.8l and older) OpenSSL libraries.
> <
> CVE-2009-3555 was mentioned by the submitter, but that was clearly 
> assigned for server-initiated renegotiation. This Squid change is 
> specifically for the client-initiated renegotiation part of the
> TLS protocol flaw.
> There may be some relevant CVE already assigned, although I've
> been unable to find it. Only CVE-2011-1473 which is for the library
> itself and disputed.
> So, is server software being assigned specific CVE (or a shared 
> generic one) for resolving this flaw? Please indicate which CVE
> Squid announcements should mention (if any).
> Thanks, Amos Jeffries Squid Software Foundation

Version: GnuPG v2.0.22 (MingW32)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.