An error that's extremely common among people doing their first work on a specific domain seems like a good fit for "rookie error". It's easy to believe most professional teams make that mistake at some point. I'd hope that it's far more rare to make that mistake twice.
No, that doesn't make sense. The errors that trip seasoned pros up are very likely to trip rookies up as well. Words mean things; rookie mistakes the mistakes that don't trip up the pros.
you're assuming the "pros" hired people with experience in the domain and retained them, and didn't let rookies do said mistakes.
No, that doesn't make sense. The errors that trip seasoned pros up are very likely to trip rookies up as well. Words mean things; rookie mistakes the mistakes that don't trip up the pros.
you're assuming the "pros" hired people with experience in the domain and retained them, and didn't let rookies do said mistakes.
Ah, the venerable "no true professional" argument. A sufficiently optimizing professional would never make these mistakes, it's true!
So I was scratching my head for a good couple of minutes trying to figure out how this works, being familiar only with HTTP Response Splitting/HTTP Cache Poisoning. So it seemed that somewhere along the years while I haven't been paying any attention to websec, it became a common practice to send requests from different clients through the same TLS connection. And due to the non conforming way HTTP 2/1.1 interop was…
Out of the ecosystems I’m familiar with, Python application servers have terrible http2 support: neither gunicorn nor uwsgi supports it, and even new hotness like uvicorn is pretty far from it.
I don’t think Ruby is doing much better? Correct me if I’m wrong.
So I was scratching my head for a good couple of minutes trying to figure out how this works, being familiar only with HTTP Response Splitting/HTTP Cache Poisoning. So it seemed that somewhere along the years while I haven't been paying any attention to websec, it became a common practice to send requests from different clients through the same TLS connection. And due to the non conforming way HTTP 2/1.1 interop was…
Out of the ecosystems I’m familiar with, Python application servers have terrible http2 support: neither gunicorn nor uwsgi supports it, and even new hotness like uvicorn is pretty far from it. I don’t think Ruby is doing much better? Correct me if I’m wrong.
But why would you need HTTP/2 perfect support in real world application server? They are never going to terminate the client traffic, they will speak with a load balancer which can speak HTTP/1.1 with them. Sure, if you are at webscale or even less you want everything on HTTP/2 for optimization sake. But in the rest of cases, even if you are in a solo project, you can easily enough put an nginx before it, or a cloud native solution, or haproxy or whatever.
I always considere NTLM and Kerberos to be very similar, so I am surprised to hear that NTLM is broken. Kerberos and HTTP/2 work just fine together. What in particular is broken with NTLM?
At least when it was released, IIS 10 supported HTTP/2, but did not support Kerberos, Negotiate or NTLM authentication over HTTP/2. https://docs.microsoft.com/en-us/iis/get-started/whats-new-i... I’m not sure that it’s a problem with HTTP/2 that Microsoft found no reason to implement Windows authentication for it.
The HTTP/2 protocol specifically makes this kind of authentication difficult. It's not just IIS, in general it doesn't quite work right.
So I was scratching my head for a good couple of minutes trying to figure out how this works, being familiar only with HTTP Response Splitting/HTTP Cache Poisoning. So it seemed that somewhere along the years while I haven't been paying any attention to websec, it became a common practice to send requests from different clients through the same TLS connection. And due to the non conforming way HTTP 2/1.1 interop was…
this kind of terrible implementation is a lot of why encrypted quic exists.
Though I think these same problems would happen over http3/quic.
Http3 is almost exactly http2 but over quic. This means the requests should be possible to force the same desyncs talked about in the article.
The title seem very much anti-HTTP/2. However, unless I missed something huge, the vast majority, if not all, of the issues found relate to how hard it is to handle HTTP/1. And it seems kinda odd to blame HTTP/2 for HTTP/1 being difficult to implement. I'm certainly not trying to downplay the seriousness of these issues. But it seems like a equally (it not more) valid title might be something like "HTTP/1: Continues…
Hi, I'm the author. This paper is about HTTP/2, and the dangerous things that happen behind the scenes with HTTP/1 when people enable it. It's arguing that enabling HTTP/2 on your front-end makes your security worse if it's downgrading behind the scenes.
This is a deliberately cheeky title, selected as a presentation title, rather than being aimed at social media where many people will read the title but not the contents. For HN I'd go with something dry like "HTTP/2-exclusive attack vectors".
I am not a "project", nor is my goal the support of online advertising as a "business model", it's information retrieval. I'm a web user. I "evaluated" HTTP pipelining 20 years ago; it has always worked great for me. It is not "fundamentall flawed" for my purposes. If it did not work, I suspect servers would have disabled it by default ages ago. They didn't. Today, I use it daily. The fact is, the majority of website…
Which servers / sites support HTTP/1.1 pipelining? This seems somewhat hard to lookup. https://en.wikipedia.org/wiki/HTTP_pipelining : says that proxies and web browsers mostly don't support it. It claims that it's easy for servers to support it, but provides no more details. It also mentions that curl removed pipelining support. https://forum.nginx.org/read.php?2,269248,269249#msg-269249 : Some person says that Ngin…
From a server point of view there is very little difference between connection reuse and pipelining. The latter just means more data might already be in the input socket when the first request is handled - but it will not be used and either sit around in socket buffers or some TLS buffer.
And i actually guess the person who mentioned pipelining just meant connection reuse.
So I was scratching my head for a good couple of minutes trying to figure out how this works, being familiar only with HTTP Response Splitting/HTTP Cache Poisoning. So it seemed that somewhere along the years while I haven't been paying any attention to websec, it became a common practice to send requests from different clients through the same TLS connection. And due to the non conforming way HTTP 2/1.1 interop was…
I think the main problem is indeed missing HTTP2 support in backend servers. This is often just a case of people not being willing to upgrade for various reasons, even if the technology they are using would support HTTP2 in newer versions.