Re: [squid-users] splunk 3.5.27-Sec Advisories

[Rafael Akchurin]

Hello Amos, Scott,

Will try building now. Shall be possible by the end of next week I hope.

Best regards,
Rafael Akchurin

> Op 28 jul. 2018 om 07:23 heeft Amos Jeffries  het 
> volgende geschreven:
> 
>> On 28/07/18 08:48, Kumpf, Scott wrote:
>> Greetings,
>> 
>> The organization I work for is running Splunk for Windows version 3.5.27 
>> which is impacted by 3 security vulnerabilities that were released earlier 
>> this year.  From what I can tell, our squid implementation was installed 
>> using an MSI package from Diladele.  It is my understanding per the 
>> advisories, the first point of contact for support is the maintainer/package 
>> vendor.  Diladele referred me back to Squid Developers and the only version 
>> that they have made available is version 3.5.27.  As I am not too familiar 
>> with source code packaging or compiling, I am in search for some guidance on 
>> available options to mitigate or remediate these vulnerabilities.  I believe 
>> 2 of them have workarounds that can be implemented by modifying the 
>> squid.conf.
>> As I  am not aware of how to determine how this version was configured at 
>> time of build therefore am not 100% certain if my implementation is even 
>> vulnerable.  Supposing the software is at risk, the advisories indicate 
>> there are patches available for each issue, however, I'm not clear on what 
>> to do with the information that the patch link presents.
>> 
> 
> The command line "squid -v" will list the build options used for your
> particular binary along with its particular version. The advisory
> section titled "Determining if your version is vulnerable:" is a
> checklist to compare against your Squid. One statement there should
> match your particular Squid installation.
> 
> The fixes for all these are in our 3.5.28 bundle from 10 days ago. I
> have not made the official announcements yet (thanks for the reminder)
> so Diladele may have not been aware.
> 
> I've cc'd Rafael on this reply and also opened an issue in the tracker
> specifically notifying of the release so they can start on that while I
> do the write-up. 
> 
> 
> HTH
> Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] splunk 3.5.27-Sec Advisories

[Amos Jeffries]

On 28/07/18 08:48, Kumpf, Scott wrote:
> Greetings,
> 
> The organization I work for is running Splunk for Windows version 3.5.27 
> which is impacted by 3 security vulnerabilities that were released earlier 
> this year.  From what I can tell, our squid implementation was installed 
> using an MSI package from Diladele.  It is my understanding per the 
> advisories, the first point of contact for support is the maintainer/package 
> vendor.  Diladele referred me back to Squid Developers and the only version 
> that they have made available is version 3.5.27.  As I am not too familiar 
> with source code packaging or compiling, I am in search for some guidance on 
> available options to mitigate or remediate these vulnerabilities.  I believe 
> 2 of them have workarounds that can be implemented by modifying the 
> squid.conf.
> As I  am not aware of how to determine how this version was configured at 
> time of build therefore am not 100% certain if my implementation is even 
> vulnerable.  Supposing the software is at risk, the advisories indicate there 
> are patches available for each issue, however, I'm not clear on what to do 
> with the information that the patch link presents.
> 

The command line "squid -v" will list the build options used for your
particular binary along with its particular version. The advisory
section titled "Determining if your version is vulnerable:" is a
checklist to compare against your Squid. One statement there should
match your particular Squid installation.

The fixes for all these are in our 3.5.28 bundle from 10 days ago. I
have not made the official announcements yet (thanks for the reminder)
so Diladele may have not been aware.

I've cc'd Rafael on this reply and also opened an issue in the tracker
specifically notifying of the release so they can start on that while I
do the write-up. 


HTH
Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] splunk 3.5.27-Sec Advisories

[Kumpf, Scott]

Greetings,

The organization I work for is running Splunk for Windows version 3.5.27 which 
is impacted by 3 security vulnerabilities that were released earlier this year. 
 From what I can tell, our squid implementation was installed using an MSI 
package from Diladele.  It is my understanding per the advisories, the first 
point of contact for support is the maintainer/package vendor.  Diladele 
referred me back to Squid Developers and the only version that they have made 
available is version 3.5.27.  As I am not too familiar with source code 
packaging or compiling, I am in search for some guidance on available options 
to mitigate or remediate these vulnerabilities.  I believe 2 of them have 
workarounds that can be implemented by modifying the squid.conf.
As I  am not aware of how to determine how this version was configured at time 
of build therefore am not 100% certain if my implementation is even vulnerable. 
 Supposing the software is at risk, the advisories indicate there are patches 
available for each issue, however, I'm not clear on what to do with the 
information that the patch link presents.

The vulnerabilities are:
SQUID-2018:3 (CVE-2018-1172), Apr 18, 2018
Fixed from 4.0.13
Denial of Service issue in ESI Response processing.
SQUID-2018:2 (CVE-2018-127), Jan 19, 2018
Fixed from 4.0.23
Denial of Service issue in HTTP Response processing.
SQUID-2018:1 (CVE-2018-124), Jan 19, 2018
Fixed from 4.0.23
Denial of Service issue in ESI Response processing.

Any and all feedback, guidance, and assistance is greatly appreciated.

Thanks,

Scott

Scott Kumpf
Sr. Network Engineer (Contractor)
Orlando Utilities Commission
Office: (407) 434-4305 / Cell: (386) 547-2698
Email: sku...@ouc.com







DISCLAIMER:
Florida has a very broad public records law. As a result, any written 
communication created or received by Orlando Utilities Commission officials and 
employees will be made available to the public and media, upon request, unless 
otherwise exempt. Under Florida law, email addresses are public records. If you 
do not want your email address released in response to a public records 
request, do not send electronic mail to this office. Instead, contact our 
office by phone or in writing.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] server persistent connections and cache

[Alex Rousskov]

[There is a potentially useful reframing of the question at the end if
you want to skip the details...]

On 07/26/2018 11:11 PM, Amos Jeffries wrote:
> On 27/07/18 16:18, Alex Rousskov wrote:

>> one could argue that Squid should honor a
>> (higher level) client and server assumption that they are talking to
>> each other (at HTTP+ level).

> Configuring persistence on/off is the way to control that, not pinning.

I disagree. Persistence is about a single connection. Pinning is about
the relationship between two connections. Honoring tunneling
expectations can be about pinning, but it is not about persistence.
Naturally, there is no pinning without persistence, but that is
irrelevant for designing how to support tunneling expectations.


>> We will probably break fewer transactions
>> that way. With that idea in mind, the "first point" becomes establishing
>> a TCP tunnel with the server, even if no client Hello pieces are forwarded.

> HTTP(S) being stateless, at that level any endpoint relying on implicit
> state is non-compliant and buggy.

What is known as HTTP statelessness is irrelevant here: HTTP CONNECT
tunnel itself is a "state"; agents have the right to rely on that state.
That state is not a state that relates to HTTP messages so there is no
contradiction with HTTP stateless principles. From HTTP point of view,
there are no HTTP messages inside that tunnel. The tunnel is a monolith
at HTTP level. Not treating it as such will break some HTTP-compliant
agents.

Same for intercepted TLS/TCP connections -- the preservation of those
TLS and TCP connections is something an HTTP-compliant agent can
legitimately rely on.


> It is *nice* not to result in visible errors, but not a requirement we
> should stick to at cost of proper behaviour.

The open question is how to define what is "proper". Any behavior will
have pros and cons associated with it. You cannot declare lack of
pinning a "proper behavior" just because most agents do not require
pinning. The decision is more complex than that because there are more
variables involved.


> The client accepted proof that Squid *was* that origin (false or not)
> order to reach said higher levels.

I disagree that being content with Squid certificate (TLS level)
constitutes acceptance of an intermediary that can switch from one
server to another at will (higher level).


> Pinning at a later time due to higher
> level stateful situation is not relevant to the bumping code actions and
> not something we need to consider at the present C2 use of S after C1
> should have pinned it.

Agreed. I do not think that contradicts what I was (and am) saying. The
question here is whether "C1 should have pinned S" after bumping C1 at
step1.


> "after C1 has pinned" - if no pinning happens at all the whole
> statement is irrelevant.

Correct. The question is whether C1 should pin S after bumping at step1.
Today, no such pinning happens, but it could be argued that this is a
bug. It is a complicated question with many variables and no obvious
answers.


> What I'm most confused about here is why S is closed when C1 dies with
> non-pinning.  _unless_ there is pinning between them they should not be
> that closely fate sharing.
> 
> Is the HTTPS message on both C1 and S saying "Connection: close" perhapse?

or perhaps some kind of still-linked FwdState/Client abort if C1 was not
closed properly/orderly.



> Off-topic; TLS has connections that do not use handshakes at all, which
> are becoming more common in TLS/1.3. So I believe such a feature may be
> coming one day, but irrelevant right now.

IIRC, all TLS versions, including v1.3, start a TLS connection with a
handshake. The scope/meaning of that handshake varies across versions,
but there is always some handshake.


>> The open question is whether S should be pinned in the case where C1 is
>> bumped at step1 (i.e., "Case 1" in Vishali's email).

> IMO in *that* specific case S should not be pinned. Because pinning
> would prevent the very reasonable actions of handling server failures by
> opening new Sn connections to finish incomplete responses to the client,
> or retaining a server connection for the quick_abort features.

IMO in that specific case S should be pinned by default because pinning
will break fewer transactions and any breakage would be easier to
triage/explain. That default may also be more "secure" because without
pinning, C1 can start requesting content from other servers, possibly
violating admin expectations that rely on vetting C1 based on TLS-level
information such as SNI).

What do we do now for intercepted HTTP clients -- are they allowed to
request content from a server they were _not_ going to when intercepted?



> Squid should instead be ensuring that the server handshake at TLS level
> matches what it would have used for C2 clean handshake. I may have
> missed it, but that is not yet being done (just TCP equivalence, not TLS).

If we do not honor the tunneling semantics (i.e., do not pin S1),