Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

portswigger.net

Post reply on HN
Print view View original

21–30 of 116 posts

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#21

Post by duskwuff »

jiggawatts wrote: post #7

I'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.

> Can you guess which two of the three popular authentication mechanisms Google doesn't use?

Google is hardly alone. Non-cookie-based authentication mechanisms aren't used (and aren't even usable) on any other public web site, either.

TLS client certificates have always been a UX nightmare. There is no standard UI for creating, installing, or selecting a certificate to use to authenticate to a web server; many browsers (especially on mobile devices) don't even support those features. There's no way to log out without closing the browser. There's no way for an average user to transfer a certificate from one device to another.

NTLM is simply irrelevant outside the scope of a Windows network. Other HTTP password mechanisms have many of the same failings as client certificates -- the UI is clunky and sometimes unavailable, and there's no standard way to log out.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#22

Post by carey »

georgyo wrote: post #14
jiggawatts wrote: post #7

I'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.

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.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#23

Post by marcosdumay »

georgyo wrote: post #14
jiggawatts wrote: post #7

I'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.

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?

Extending the sibling comment a bit, if you run it exclusively on HTTPS, with Firefox or some other browser that understands it shouldn't share your password with any site that asks, it's just a bug-prone, slow authentication mechanism.

But MS has also the "Negotiate" protocol they made to replace NTLM on IE (because even the IE team considered it irremediably broken). That one is a variant of Kerberos, and a lot of people say just NTLM when they mean "Negotiate with a possible downgrade to NTLM".

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#24

Post by tptacek »

mhitza wrote: post #20

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…

It's worth knowing that this is an extension of a very widespread attack on HTTP/1.1; many (maybe most?) 1.1 implementations were recently broken by desync just a couple years ago.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#27

Post by jiggawatts »

duskwuff wrote: post #21
jiggawatts wrote: post #7

I'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.

> Can you guess which two of the three popular authentication mechanisms Google doesn't use? Google is hardly alone. Non-cookie-based authentication mechanisms aren't used (and aren't even usable ) on any other public web site, either. TLS client certificates have always been a UX nightmare. There is no standard UI for creating, installing, or selecting a certificate to use to authenticate to a web server; many brows…

> aren't used ... on any other public web site, either.

Internal-use web sites are a thing, however. A very common, heavily used thing. Many of them use NTLM or Kerberos authentication.

> TLS client certificates have always been a UX nightmare.

Which isn't an issue for APIs accessed over HTTPS, many of which are "public" yet use client certificates for authentication.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#28

Post by ClumsyPilot »

duskwuff wrote: post #21
jiggawatts wrote: post #7

I'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.

> Can you guess which two of the three popular authentication mechanisms Google doesn't use? Google is hardly alone. Non-cookie-based authentication mechanisms aren't used (and aren't even usable ) on any other public web site, either. TLS client certificates have always been a UX nightmare. There is no standard UI for creating, installing, or selecting a certificate to use to authenticate to a web server; many brows…

"There's no way to log out without closing the browser. "

Itw like theu gave up halfway when inplementing it. Wtf

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#29

Post by chrismorgan »

carey wrote: post #2

Given 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?

These vulnerabilities are all from badly-written HTTP/2 → HTTP/1.1 translations. Most of them come from simple carelessness, rookie errors that should never have been made, dumping untrusted bytes from an HTTP/2 value into the HTTP/1.1 byte stream. This is security 101, straightforward injection attacks with absolutely nothing HTTP-specific in it.

Some of them are a little more complex, requiring actual HTTP/2 and HTTP/1.1 knowledge (largely meaning HTTP/2 framing and the content-length and transfer-encoding headers), but not most of them.

Is HTTP/2 actually worse? Not in the slightest; HTTP/1.1 is the problem here. This is growing pains from compatibility measures as part of removing the problems of an unstructured text protocol. If you have a pure-HTTP/2 system and don’t ever do the downgrade, you’re in a better position.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#30

Post by dagenix »

1vuio0pswjnm7 wrote: post #19
jiggawatts wrote: post #7

I'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.

"HTTP/2's binary format means you can't use classic general-purpose tools like netcat and openssl. HTTP/2's complexity means you can't easily implement your own client, so you'll need to use a library." IOW, HTTP/2 is not designed for users. It is designed for online advertisers and the companies that serve them. How do I know this. Because HTTP/1.1 pipelining still works great. I am using it on a separate task as I…

HTTP/1.1 pipelining is fundamentally flawed and largely unused. There isn't some conspiracy not to use it - many, many projects evaluated it and pretty much all came to that same conclusion.
Post reply on HN