HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
1–10 of 116 posts
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#2Given the long history of request parsing vulnerabilities in HTTP/1.1 servers and proxies, is HTTP/2 actually worse, or have most of the HTTP/1.1 bugs just been fixed already?
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#3Given the long history of request parsing vulnerabilities in HTTP/1.1 servers and proxies, is HTTP/2 actually worse, or have most of the HTTP/1.1 bugs just been fixed already?
Is an new bucket leaking in a dozen places worse than an old one with all leaks fixed? I would say yes until those holes in the new one are also fixed.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#4Given the long history of request parsing vulnerabilities in HTTP/1.1 servers and proxies, is HTTP/2 actually worse, or have most of the HTTP/1.1 bugs just been fixed already?
When I implemented an HTTP2 server several years ago it was all of the "fun" of HTTP 1.1 parsing and semantics plus the extra challenges of the HTTP2 optimizations such as HPACK, mapping the abbreviated headers to cache in-memory representations, stream management, and if you supported Push Promises then that too.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#5> This means there's little room for ambiguity about the length of a message, and might leave you wondering how desync attacks using HTTP/2 are possible. The answer is HTTP/2 downgrading.
I would guess a huge percentage of attacks are made possible because of protocol or algorithm downgrading. I wonder if built in downgrading abilities into protocols is a security smell.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#6[deleted]
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#7I've been burnt one too many times by trying to "upgrade" to HTTP/2.
It simply broke client certificate authentication and NTLM authentication, leaving only cookie-based authentication fully functional.
Can you guess which two of the three popular authentication mechanisms Google doesn't use?
It's not a protocol designed to advance the Internet, it's a protocol designed by Google to shave 1% off their network bill.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#8I've been burnt one too many times by trying to "upgrade" to HTTP/2. It simply broke client certificate authentication and NTLM authentication, leaving only cookie-based authentication fully functional. Can you guess which two of the three popular authentication mechanisms Google doesn't use? It's not a protocol designed to advance the Internet, it's a protocol designed by Google to shave 1% off their network bill.
To be fair, NTLM authentication being broken has nothing to do with HTTP/2.
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#9I'm not a security person at all. Is there a quick explanation for how these attacks allow the attacker to mess with other clients' requests?
I'm also confused at their usage of the word "prefix". Did they mean "suffix"? Or does "prefix" have a specific meaning in this case?
Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections
#10> This means there's little room for ambiguity about the length of a message, and might leave you wondering how desync attacks using HTTP/2 are possible. The answer is HTTP/2 downgrading. I would guess a huge percentage of attacks are made possible because of protocol or algorithm downgrading. I wonder if built in downgrading abilities into protocols is a security smell.
The shown attacks aren't a true case of protocol downgrading, but of an overeager direct translation of request headers across protocols. The attacks weren't possible because the client is doing some backhanded protocol negotiation, but because the client/front/back are being very directly connected.
If, instead of forwarding a direct translation of the headers, the front ends calculated the relevant requests and sent that, there wouldn't have been any HTTP header attacks (it would have been much slower though).