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

Hash: SHA1

On 18/07/2015 2:09 a.m., wrote:
>> 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
> Use CVE-2015-5400.

Thank you!

>> This months release of Squid HTTP proxy, version 3.5.6, contains fixe
>> for two security issues.
>> Squid up to and including 3.5.5 are apparently vulnerable to DoS
>> attack from malicious clients using repeated TLS renegotiation
>> messages.
> We have a few questions about this.
> First, we probably don't understand your build process. The only
> mentions of the substring "renegotiate" in squid-3.5.6.tar.bz2 are:
>     - TLS: Disable client-initiated renegotiation
>   #if defined(TLSEXT_TYPE_renegotiate)
>               TLSEXT_TYPE_renegotiate,
>   #endif
>   static void
>   ssl_info_cb(const SSL *ssl, int where, int ret)
>   [ ... ]
>   #endif
>   configureSslContext
>   ...
>       SSL_CTX_set_info_callback(sslContext, ssl_info_cb);
>   #endif
>   sslCreateClientContext
>   ...
>       SSL_CTX_set_info_callback(sslContext, ssl_info_cb);
>   #endif
> The only mention of the substring "renegotiate" in squid-3.5.5.tar.bz2
> is:
>   #if defined(TLSEXT_TYPE_renegotiate)
>               TLSEXT_TYPE_renegotiate,
>   #endif
> doesn't seem to
> mention the change.
> How do these 3.5.6 changes disable anything, or serve as one of two
> "fixes for two security issues"? Are you just providing a (not widely
> documented) build option so that a repackager or end user could define

The relevant code is all the parts wrapped in:

When the OpenSSL library provides that flag definition, we set it on all
client TLS connections at the end of the initial TLS handshake. Using
the callback mechanism library provides to signal handshake completion.

The result is that the library then blocks renegotiation attempts by the
client at any later time in the TLS connections existence.

This seem to be relevant to OpenSSL 0.9.8l up to somewhere around 1.0.2.
After 1.0.2 the library apparently always refuses to perform that type
of renegotiation and the flag was removed.

It's only mentioned in the release announcement at present.

> In that situation, we don't believe there should be a CVE ID for the
> official Squid distribution, because the change is about adding
> functionality in the form of a new, non-default option. If a
> repackager decided to build with SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS and
> then announce their 3.5.6 renegotiation change as a required security
> update for their customers, then the repackager could have a CVE ID.
> Second, we don't know what you mean by "CVE-2009-3555 ... was clearly
> assigned for server-initiated renegotiation." This statement is,
> however, not critical to CVE assignment, so we won't try to start a
> discussion of that. The principal reason that CVE-2009-3555 can't be
> correct is that CVE-2009-3555 isn't about resource-consumption DoS.
>> CVE-2011-1473 which is for the library itself and disputed
> Right, in a case where there should be a CVE ID, we feel that the
> vulnerable product would be specific server-side code, not a
> general-purpose library.
> To conclude, if the position of the Squid developers is that
> client-initiated renegotiation must be denied (e.g., because it can
> lead to resource-consumption DoS, and there aren't any supported Squid
> use cases where you feel it's important to let a client renegotiate),
> and you have changed your code to take this position by default, then
> you can have a CVE ID. Otherwise, we think not.

Our position matches all of the above except;

 - the "must" in "must be denied". "should" would be closer. It has been
a public issue for a long time and to our knowledge no actual DoS has

 - other products had issues with client certificate authentication.
None so far for us. If that is complained about we will likely re-enable
it for that specific use case. Intention at this time is to keep the
default as disabled.

I'm half-hearted about CVE assignment. Since its all academic for
installations building against up-to-date OpenSSL versions, and user
requests to fix were based on QualSys test audits rather than real
network problems.

Thank you for the feedback.

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.