Re: Resend: HTTP/2 extended CONNECT and HTTP Digest authentication underspecified interaction

Ben and David, thank you for validating my concern.

It would seem that solutions to address this should focus on changes
to extended CONNECT, which introduced the inconsistency, and which is
not as old or as widely deployed as, say, support for HTTP Digest auth.

Perhaps HTTP/[23] extended CONNECT might be enhanced so that
if a gateway changes the request method, it adds a new header --
e.g. "Base-Method" -- (if not already present) containing the request
method of the original client request.  This suggests "Base-*" for
similar transformations.  Alternatively, the original request might
be encoded into a header "SF-Request" with structured fields to allow
for future expansion.

An origin server performing HTTP Digest authentication might check for
this new header if HTTP/[23] extended CONNECT is in use (or maybe
even unconditionally).

For anything that can already see the request, the request method is not
secret.  Also, adding the request method into the hash func for Digest
authentication is not very effective at adding entropy in the case
where 100% of the original requests use GET.  (e.g. wss://)


Another alternative would be to extend HTTP Digest authentication to
include a parameter in Authorization header for the method used in the
digest calculation, similar to 'nonce'.  This might help HTTP Digest
authentication, but would not be a general solution to address
extended CONNECT changing the method.

Cheers, Glenn

On Mon, Sep 09, 2024 at 06:03:01PM +0000, Ben Schwartz wrote:
> This is a very interesting situation.  Naively, it would seem that "CONNECT" is the method.  However, if the backend is speaking HTTP/1.1 through a WebSocket+HTTP/2 gateway, then the method will be rewritten, and the client and origin will disagree about the method.  Uh-oh...
> 
> I note that this question applies equally to the MASQUE protocols as well.
> 
> --Ben
> ________________________________
> From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
> Sent: Saturday, September 7, 2024 3:34 PM
> To: ietf-http-wg@w3.org <ietf-http-wg@w3.org>
> Subject: Resend: HTTP/2 extended CONNECT and HTTP Digest authentication underspecified interaction
> 
> There appears to be an underspecified interaction with HTTP/2 extended
> CONNECT and HTTP Digest authentication when clients evaluate wss://.
> 
> With the HTTP/2 extended CONNECT method [1], the :method is CONNECT.
> With wss:// using HTTP/2 extended CONNECT, the :method is CONNECT.
> 
> If there is HTTP Digest authentication [2], then the HTTP request
> method is part of A2 if the qop parameter's value is "auth" or is
> unspecified. [3]
> 
> An inconsistency has been reported to me: [4]
> With wss://, Firefox and Chromium both produce a digest using "GET" as
> the HTTP method, but if using an HTTP/2 connection, use HTTP/2 extended
> CONNECT for wss://.  For HTTP/2 extended CONNECT, lighttpd produces a
> digest using "CONNECT" as the HTTP method, and HTTP Digest
> authentication fails due to the mismatch of the hashes.
> 
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8441*section-5__;Iw!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SP7tqQN0g$  notes that
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6455__;!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SNrZLfEhA$  uses a GET-based request in
> WebSockets opening handshake, but I did not find additional relevant
> references to GET.
> 
> Which is proper behavior with wss:// using HTTP/2 extended CONNECT and
> HTTP Digest authentication?  Should "CONNECT" be used as the HTTP method
> for A2, or should "GET" be used as the HTTP method for A2, even though
> :method is CONNECT?  Should this be an Errata to RFC8441 to better
> specify the correct behavior with HTTP2 (and HTTP/3)?
> 
> Scripts to reproduce the issue can be found in [4].
> 
> Thank you for your input.
> Cheers, Glenn
> 
> [1] Bootstrapping WebSockets with HTTP/2
>     https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8441__;!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SO0ieiuJg$
> 
> [2] HTTP Digest Access Authentication
>     https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7616__;!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SN3O7gn9g$
> 
> [3] https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7616*section-3.4.3__;Iw!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SN0bz9bqA$
> 
> [4] https://urldefense.com/v3/__https://redmine.lighttpd.net/boards/2/topics/11676__;!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SP1M5JQhw$
>

Received on Monday, 9 September 2024 20:39:59 UTC