Supporting HTTP/2: HTTP/1.1 must die

[JLLeitschuh]

At BlackHat & DEF CON 33, James Kettle detailed that HTTP/1.1 contains fundamental desynchronization security vulnerabilities that researchers keep finding and will continue to find due to the poorly defined boundaries between requests. In that research, bug bounty hunters found $300k+ worth of bounties due to a novel HTTP Request Splitting vulnerability.

This research is summarized here: https://http1mustdie.com/

James believes that there will continue to be new, and noverl HTTP request smuggling vulnerabilities due to the fundamental insecure nature of HTTP/1.1.

His proposed mitigation is to encourage all backing servers to support HTTP/2.

I know that a ticket on this topic #5462, however given that this research is new, and situationally relevant to express, it seems like it was appropriate to create a new issue.

[bjohansebas]

I understand, but that still doesn’t fall under Express’ responsibilities. Express is just a wrapper to make it easier to create servers with Node.js, and we won’t stop supporting HTTP/1.1 (I’m not speaking on behalf of the team here). We haven’t achieved HTTP/2 yet, and QUIC is not yet available in Node.js.

In the end, this would be more of a Node.js problem, but I don’t think they can do much about it either.

[ctcpip]

(converted to discussion)

@JLLeitschuh is your goal for this issue to encourage us to redouble efforts to support HTTP/2 ?

[SheldonWBM]

#6755 (reply in thread)
Not necessarily. Instructions commonly suggest HTTP/2 middlewares that are not compatible with the latest version of Node (24), or staying with officially supported HTTP/1.1. But, you can solve the issue by manually implementing a compatibility wrapper that seems to work without any extra packages. The question is valid? If Express does not support HTTP/2, should we transition to other frameworks, attempt middlewares that may not have the benefits, a manual wrapper (and what are the downsides) or, wait for Express to support HTTP/2

[JLLeitschuh]

@JLLeitschuh is your goal for this issue to encourage us to redouble efforts to support HTTP/2 ?

Yes, that is the direction I would encourage given the current state of the research

[JLLeitschuh]

I also imagine that any middle-wear that does any transformation from HTTP/2 to HTTP/1.1 is possibly vulnerable to protocol misinterpretation issues. So if that is what those modules are doing, than that's probably likely still a problem.

I haven't dug into their specific implementation details though to explore one way or another