A very cheap attack is to chain CDNs into a nice circle. This is what Via protects against: https://blog.cloudflare.com/preventing-malicious-request-loo...
Just because a browser doesn't use a header does not make the header superfluous.
Disclosure: I work at cloudflare.
Cache-Control: max-age=0, s-maxage=3600
I mean, Via might be useful as a safety check against mistake, but I'm not getting the security angle.
It's like relying on the From: header in an e-mail.
If. Much, if not most, server software is written under the implicit assumption that it will not be under attack.
If CDN A proxies requests to CDN B and CDN B proxies requests to CDN A then those two will DoS eachother fairly quickly.
There is no attacker inbetween to strip the Via, that would be counterproductive to the attack.
Email has this too; the Received: header. If you manage to get a loop between two MTAs going they will detect it by seeing themselves in the Received: header list.
More debatable perhaps is Via, which is required (by RFC7230) to be added to the response by any proxy through which it passes to identify the proxy. This can be something useful like the proxy’s hostname, but is more likely to be a generic identifier like “vegur”, “varnish”, or “squid”. Removing (or not setting) this header is technically a spec violation, but no browsers do anything with it, so it’s reasonably safe to get rid of it if you want to.
Actually, it isn’t “debatable,” since the debate occurred, and a decision was made, and published. That’s what RFCs are for.
To ignore them with such wanton disregard speaks volumes.
Edit: to clarify, I didn't mean that RFCs should not be debated at all, only that disregarding this because "no browsers do anything with it" didn't seem like a good justification or stance.
If there is a standard published for something, follow it or publish your own RFC. Don't just nitpick the bits you want and break clients in the process.
I agree that standards can and should be replaced/amended to over time, but I kinda see what GP's point is getting at.
Ignoring is usually fine. Dropping is not.
Of course that isn't what is happening at all. Instead we're having the usual heap of politics and ever-faster update cycles. So I'd agree to say that web standards failed - but not that they were meant as a guidiance in the first place.
<nitpick> Only people who like lice eggs nitpick the bits they want. Others pick-and-choose. </nitpick>
Thus it may not be useful to the browser. But the article saying that its usage is debatable in this context is very wrong.
A MUST is a MUST, in my opinion - and too often there are serious issues in (web) communication because people ignore them as they see fit.
In either event - no one is saying that you should wait to change an RFC (or wording in an RFC) until it's fully deprecated and completely not in use - but a lot of people use RFC's for researching issues, especially in areas they are not 100% familiar with. Coming across a MUST and seeing that some software vendor or hardware vendor doesn't follow it is all too common. This delays certain projects by weeks, sometimes longer, and costs the involved companies lots of money. RFC's exist for a reason...because the approved standards are just expected to be followed when creating new things.
At any rate there's lots of things you just have to ignore, drop, reject, and otherwise muck about with in order to run a sane network. These standards are not written with software experience. They're written much in a vacuum and out of touch. This varies widely across RFCs so it might not apply to RFCs you like.
Example of a MUST for SIP and HTTP: line folding and comments in headers. Apart from being crap for performance (so much for being able to zero-copy a header value as just a pointer+len) there's zero legitimate use for these "features" of the syntax. Simply rejecting such messages is in your best interest as a network operator.
Or you can debate them as much as you want, or even publish a new and improved version and perhaps people will decide to follow that instead. Or perhaps they’ll just do whatever they feel like.
There's a really important reason for not sending the Via header in the request: it disables compression, by default, in most major web-servers!
· nginx defaults gzip_proxied to "off", where 'proxied' is determined by the presence of the Via header: http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip...
· The same goes for IIS 7 & IIS 8 via noCompressionForProxies defaulting to "true" - https://docs.microsoft.com/en-us/iis/configuration/system.we...
· Apache's mod_deflate doesn't do this (thankfully).
This has an immediately negative impact on performance and, in many cases, cost: the origin server is sending more bytes over the wire, and network transit is often a non-trivial cost for those on AWS, Azure, et. al.
Akamai also has a post on this: https://community.akamai.com/community/web-performance/blog/...
Note: I used to work at Cloudflare, and believe they (we!) made the right decision here. There are other mechanisms that can be used to detect proxy loops, and there are also cases where customers may "stack" edge network vendors (migration, specific feature needs, application complexity).
PS: Hi David! :)
So is this Fastly article suggesting a different point of view?
Via is a MUST https://tools.ietf.org/html/rfc7230#section-5.7.1
Forwarded is OPTIONAL https://tools.ietf.org/html/rfc7239#section-4
Protecting against loops only works with MUST headers.
Via => proxy/organization name chain where the response came from
X-Forwarded-For => ip address chain where the request came from