11–20 of 26 posts
I'll note articles about HTTP2.0 vulnerabilities have been posted with some regularity here: https://news.ycombinator.com/item?id=44909416
It over-reaches with argument about disallowing http/1.1.
Parsers should be better.
Moving to another protocol won't solve the issue. It will be written by the same careless engineers. So same companies will have the same issues or worse...
We just lose readability/debuggability/accesibility.
> If we want a secure web, HTTP/1.1 must die. Yes, the corporations and insitutions and their economic transactions must be the highest and only priority. I hear that a lot from commercial people with commercial blinders on. They simply cannot see beyond their context and realize the web, http/1.1 is used by human people that don't have the same use cases or incredibly stringent identity verification needs. Human use…
The author is only arguing against HTTP/1.1 for use between proxies and backends. Explicitly so: > Note that disabling HTTP/1 between the browser and the front-end is not required
I dont know, arguing that http/2 is safer overall is a... bold claim. It is sufficiently complex that there is no standard implementation in the Python standard library, and even third party library support is all over the place. requests doesn't support it; httpx has experimental, partial, pre-1.0 support. Python http/2 servers are virtually unavailable at all . And it's not just Python - I remember battling memory…
Perhaps it isn’t that easy, but it could be put in common and used a bit everywhere.
It seems they're very familiar with some HTTP1.1 problems. I suspect they'll feel less confident in HTTP2.0 if they spent some time there. I'll note articles about HTTP2.0 vulnerabilities have been posted with some regularity here: https://news.ycombinator.com/item?id=44909416
Is there a reason you don't find this persuasive?
The article is a nice read on request smuggling. It over-reaches with argument about disallowing http/1.1. Parsers should be better. Moving to another protocol won't solve the issue. It will be written by the same careless engineers. So same companies will have the same issues or worse... We just lose readability/debuggability/accesibility.
The post makes the case that HTTP/2 is systematically less vulnerable than HTTP/1 to the kinds of vulnerabilities it's talking about.
I dont know, arguing that http/2 is safer overall is a... bold claim. It is sufficiently complex that there is no standard implementation in the Python standard library, and even third party library support is all over the place. requests doesn't support it; httpx has experimental, partial, pre-1.0 support. Python http/2 servers are virtually unavailable at all . And it's not just Python - I remember battling memory…
> If we want a secure web, HTTP/1.1 must die. Yes, the corporations and insitutions and their economic transactions must be the highest and only priority. I hear that a lot from commercial people with commercial blinders on. They simply cannot see beyond their context and realize the web, http/1.1 is used by human people that don't have the same use cases or incredibly stringent identity verification needs. Human use…
The author is only arguing against HTTP/1.1 for use between proxies and backends. Explicitly so: > Note that disabling HTTP/1 between the browser and the front-end is not required
The irony that near the foot of the article it encourages people to "Avoid niche webservers" because "Apache and nginx are lower-risk" is quite strong, given that my publicfile logs show that most of the continual barrage of attacks a public WWW server like mine is subject to are query parameter injection attempts, and attacks quite evidently directed against WordPress, Apache, AWS, and these claimed "lower risk" softwares. (There was another lengthy probe to find out where WordPress was installed a couple of minutes ago, as I write this. Moreover, the attacker who has apparently sorted every potentially vulnerable PHP script into alphabetical order and just runs through them must be unwittingly helping security people, I would have thought. (-:)
Switching from my so-called "niche webserver", which does not have these mechanisms to be exploited, to Apache and nginx would be a major retrograde step. Not least because djbwares publicfile nowadays rejects HTTP/0.9 and HTTP/1.0 by default, and I would be going back to accepting them, were I foolish enough to take this paper's advice.
"Reject requests that have a body" might have been the one bit of applicable good advice that the paper has, back in October 1999. But then publicfile came along, in November, whose manual has from the start pointed out (https://cr.yp.to/publicfile/httpd.html) that publicfile httpd rejects requests that have content lengths or transfer encodings. It's a quarter of a century late to be handing out that advice as if it were a new security idea.
And the whole idea that this is "niche webservers" is a bit suspect. I publish a consolidated djbwares that incorporates publicfile. But the world has quite a few other cut down versions (dropping ftpd being a popular choice), homages that are "inspired by publicfile" but not written in C, and outright repackagings of the still-available original. It's perhaps not as niche as one might believe by only looking at a single variant.
I might be in the vanguard in the publicfile universe of making HTTP/0.9 and HTTP/1.0 not available in the default configuration, although there is a very quiet avalanche of that happening elsewhere. I'm certainly not persuaded by this paper, though, based entirely upon a worldview, that publicfile is direct evidence of not being universal truth, to consider that I need do anything at all about HTTP/1.1. I have no back-end servers, no reverse proxies, no CGI, no PHP, no WordPress, no acceptance of requests with bodies, and no vulnerability to these "desync" problems that are purportedly the reason that I should switch over to the monoculture and then switch again because the monoculture "must die".
It seems they're very familiar with some HTTP1.1 problems. I suspect they'll feel less confident in HTTP2.0 if they spent some time there. I'll note articles about HTTP2.0 vulnerabilities have been posted with some regularity here: https://news.ycombinator.com/item?id=44909416
The section "How secure is HTTP/2 compared to HTTP/1?" ( https://portswigger.net/research/http1-must-die#how-secure-i... ) responds to this. In short, there's an entire known class of vulnerabilities that affects HTTP/1 but not HTTP/2, and it's not feasible for HTTP/1 to close the entire vulnerability class (rather than playing whack-a-mole with bugs in individual implementations) because of backwards compatibility.…
It's quite possible the old issues are worse than the new ones, but it's not obvious that's the case.