Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 30 Apr 2015 22:14:19 +1200
From: Amos Jeffries <>
Subject: Re: Re: CVE policy clarification request

Hash: SHA1

On 30/04/2015 9:19 a.m., wrote:
>> My observation of Mitre allocations has been that when a bug B is
>> only acting because of another A exploited first the CVE gets
>> assigned to the A. In this case the client willingness to accept
>> fake certificate makes it vulnerable to mistakes in the proxy.
>> Is my observation correct or does the server validation bug get a
>> CVE assignment anyway?
> We feel that you are eligible to have a CVE ID for the "server
> cert validation was a bit naive" issue if you would like to have
> one.
> Here, behavior B is the "server cert validation was a bit naive" 
> issue. Behavior A is "the client is known to accept one blatantly
> fake server certificate." However, there might be scenarios in
> which behavior A is intended. For example, maybe an organization
> has unusual requirements that are well addressed by the "ssl_bump
> client-first" choice. In particular, the organization physically
> disconnects all untrusted systems, as well as the external network
> connection, at a time when the client accepts the fake certificate,
> thereby ensuring that the client is using an expected fake
> certificate. The client users are trained to accept fake
> certificates at that instant of time, and at no other times. The
> client users are, however, relying on Squid to do proper server
> cert validation at all times. If Squid is not doing proper server
> cert validation, then you can report that as a Squid vulnerability
> and have a CVE ID. Should we proceed with sending that CVE ID?

Okay then, yes please.

"Squid HTTP Proxy configured with client-first SSL bumping does not
correctly validate server certificate hostname fields. As a result
malicious server responses can wrongly be presented through the proxy
to clients as secure authenticated HTTPS responses."

Affected versions are:
 3.2.1 -> 3.2.13
 3.3.1 -> 3.3.13
 3.4.1 -> 3.4.12
 3.5.1 -> 3.5.3

Fixed in versions (to be released in ~24hrs) 3.5.4, 3.4.13, 3.3.14,
and 3.2.14.

Upstream advisory (when published) will be at:

Amos Jeffries
Squid Software Fundation
Version: GnuPG v2.0.22 (MingW32)


Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ