Follow @Openwall on Twitter for new release announcements and other news
[<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

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.