Re: [fetch] Access to the HTTP trailer (#34)

@louiscryan No, that's not correct - that is, the objections are not limited to that. It's about a scope of authority separation that trailers introduce.

Consider, for example, RFC 6797 or RFC 7469. Both of these explicitly restrict processing to the first instance of the header field (e.g. http://tools.ietf.org/html/rfc6797#section-8.1 http://tools.ietf.org/html/rfc7469#section-2.3.1 ). This wasn't accidental, but predicated by a concern about the separation between the capabilities being expressed by someone who controls a given resource and those who control the domain/server. In many (most) systems, the headers are handled by a 'trusted' system (such as the web server), which handles access controls about what can be set where and by whom, and then shunts processing of the body off to other, less-trusted systems (think CGI scripts, although I'm sure you can insert your favourite framework here). The trusted process handles the preamble generation, and then everything else is handed to the untrusted process and no further parsing/inspection is needed by the server.

To put this more concretely, consider a server that wished to delegate the production of content bodies to some 'untrusted' process, which may include the production of chunked bodies. In order to safely sanitize headers (especially security-relevant headers), the server implementation would need to inspect/process all chunks and filter them along the way, versus the current behaviour of filtering them up at the forefront.

This is just one example where the state of non-implementation in browsers is a security benefit to server operators. While it may be perfectly fine when all elements of the data production are trusted (such as the cases @mnot raises), I don't believe that the threat models are the same (nor do I think Mark would suggest they are), thus we can't reach a conclusion that what is good for the goose is good for the gander.

This sort of system, as a concept, is a common source of attacks and vulnerabilities. For example, consider certificates that contain multiple common names. Some CAs would only validate the first instance as a domain name, and let the remaining instances be requestor-controlled. However, some applications would check the first CN, others would check the last CN, and there would be confusion such that those who looked at the last CN would be seeing attacker controlled data. Or, to use another certificate-based example, Moxie Marlinspike's null termination attack (which related to ambiguity whether systems checked the name from the beginning up to the null, or checked the name from the end).

Even within HTTP, you've had situations like Request/Response smuggling vectors leading to confusion.

I hope you can see that there is a whole host of systemic errors that emerge when there are multiple ways to represent something, when implementations may support one, the other, or both, and when there is additional filtering overhead beyond "out of sight, out of mind". This is why we (intentionally) have not supported trailing headers and are loathe to do so, and why it's such an exceptionally high bar outside of niche use cases that may not have the same security concerns.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/34#issuecomment-119705158