In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes.
This was done because the initial specification for HTTP did not specify explicitly a charset, and it was assumed to be ISO-8859-1 for historical reasons.
If the password contains characters that cannot be represented in ISO-8859-1, they are silently replaced by `?`. This happens with passwords that contain Chinese, Cyrillic or Greek characters, for example: `αβ123` converts to `??123`.
An attacker can send a request with a digest `Authorization` header crafted with a password made of only `?` characters; the server would match any password of the same length that contains non-ISO-8859-1 characters.
Recent HTTP Digest [RFC-7616](https://datatracker.ietf.org/doc/html/rfc7616) supports a `charset` parameters that defaults to UTF-8 that allows for correct encoding/decoding of passwords.
In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present).
This was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).
This mismatch can cause a number of problems that may be classified as vulnerabilities such as:
*
URI constructions (for example, for redirects -- this is typical for login pages)
*
Virtual host selection
*
Reverse proxying
*
Misleading logs
*
Etc.
Given that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant.