Hacker News new | ask | show | jobs
by supermatt 1787 days ago
> It is very clear, no reason to be rude.

Its not - feel free to quote a single line from that article that talks about whether they are talking about transfer encoding or content encoding.

Im not sure what you find rude about it? The caps were for emphasis. No offense intended...

> People still believe that the world can be neatly divided into 7 to 8 boxes?

You are the one wanting to redefine what transport means.

> the very people that pay them to be their CDN are the people who deploy those middle boxes that break everything

Brotli compression is a switch in CF. You can turn it on and off. Default on for free/pro and off for business/enterprise.

Further digging into CFs behaviour reveals: "The Accept-Encoding header is not respected and will be removed.". It appears they decide what to compress based on UA. Again, this doesnt sound like any upstream middlebox protection, as they strip the header anyway - i.e. it never gets forwarded to origin, so its got nothing to do with upstream provider.

> Squid Proxy very much looks at the encoding

Point me at the issue in squid where it cant handle an unknown encoding.

> I hope you have proof that this is a mitigation for BREACH applied to plaintext HTTP

The primary mitigation for BREACH is to disable content-encoding when using TLS. As I mentioned, it could be they have applied this mitigation in reverse, to http instead of https. http://www.breachattack.com/#mitigations

1 comments

>Further digging into CFs behaviour reveals: "The Accept-Encoding header is not respected and will be removed.". It appears they decide what to compress based on UA. Again, this doesnt sound like any upstream middlebox protection, as they strip the header anyway - i.e. it never gets forwarded to origin, so its got nothing to do with upstream provider.

Most browsers won't offer Brotli, hence UA Analysis is more reliable.

>Point me at the issue in squid where it cant handle an unknown encoding.

Not necessarily squid itself, but i know plenty of middleware boxes that have these issues, in part they are based on squid. Sophos is an example if you run an older box.

> it could be they have applied this mitigation in reverse, to http instead of https. http://www.breachattack.com/#mitigations

But where is proof of that

>You are the one wanting to redefine what transport means.

Not really, you're the one wanting to put the world into 7 boxes.

>Its not - feel free to quote a single line from that article that talks about whether they are talking about transfer encoding or content encoding.

Look for "How does CF handle Brotli?" then read the paragraph after.

>Im not sure what you find rude about it?

Your response was condescending at best.

>Again, this doesnt sound like any upstream middlebox protection, as they strip the header anyway - i.e. it never gets forwarded to origin, so its got nothing to do with upstream provider.

The middlebox will foward the UA in almost all cases, so from CF's perspective, a middlebox will look like a normal user agent with possible Brotli capabilities.

I think you're confusing middleboxes and proxies with the reverse proxy people commonly put behind Cloudflare here, which while technically a middlebox is rarely called that.

I guess you just want to be argumentative.

  - You think UA is more reliable than accept-encoding? wtf.
  - I ask to show me the so-called issues with squid, and you cant.
  - You ask me to prove this isnt a BREACH mitigation implemented incorrectly - im not a CF employee. Are you?
  - OSI levels are a thing that professionals use to communicate about what we are discussing here. If you cant accept that maybe you dont belong on the discussion?
  - ask you to quote EXACTLY where it says about transfer vs content encoding, and you cant.
Reply if you feel the need, but I have no desire to try and educate the intolerable. I see this is a habit of yours from your comment history. Your user comment is apt.