We're leaving Cloudflare – here's why – Pale Moon • Hacker News Board

Re: We're leaving Cloudflare – here's why – Pale Moon

#21

Post by supermatt » Wed, Jul 28, 2021, 10:40 AM UTC

zaarn wrote: post #20

supermatt wrote: post #19

Earlier quoted context omitted.

> There is no transport compression in HTTP? Have you ever heard of Content-Encoding? You seem to be under the impression that this is somehow not a transport compression in some way (it is). HTTP is TRANSFER, not TRANSPORT. It is an OSI layer 7 protocol. Transport compression (in TLS) occurs at a different layer (OSI layer 5, the session layer). Of course i have heard of content encoding - i literally stated it in n…

>I also said there is a difference between TRANSFER-encoding (which is a choice of middleboxes) and CONTENT-encoding (which is a choice of client) - and that its not clear from the author which they were talking about. It is very clear, no reason to be rude. >HTTP is TRANSFER, not TRANSPORT. It is an OSI layer 7 protocol. Transport compression (in TLS) occurs at a different layer (OSI layer 5, the session layer). Peo…

> 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

Re: We're leaving Cloudflare – here's why – Pale Moon

#22

Post by zaarn » Wed, Jul 28, 2021, 11:48 AM UTC

supermatt wrote: post #21

zaarn wrote: post #20

Earlier quoted context omitted.

>I also said there is a difference between TRANSFER-encoding (which is a choice of middleboxes) and CONTENT-encoding (which is a choice of client) - and that its not clear from the author which they were talking about. It is very clear, no reason to be rude. >HTTP is TRANSFER, not TRANSPORT. It is an OSI layer 7 protocol. Transport compression (in TLS) occurs at a different layer (OSI layer 5, the session layer). Peo…

> 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. >…

>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.

Re: We're leaving Cloudflare – here's why – Pale Moon

#23

Post by supermatt » Wed, Jul 28, 2021, 12:38 PM UTC

zaarn wrote: post #22

supermatt wrote: post #21

Earlier quoted context omitted.

> 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. >…

>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 reliab…

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.