HTTP/2 is downgraded to HTTP/1.1 when using Negotiate (Kerberos/NTLM) authentication

Summary

When accessing Jira via HTTP/2, the browser downgrades the connection to HTTP/1.1, even though HTTP/2 is configured

Environment

Clients connect on HTTP/2, and a third party solution enforces Negotiate (Kerberos/NTLM) authentication

Diagnosis

Run the command

Confirm the output includes the following lines:

and

ℹ️ The value of www-authenticate could be any of: Negotiate , NTLM

Cause

Jira itself does not implement Kerberos or NTLM authentication via the WWW-Authenticate header. However, Jira can be customised to do so via a third party solution, like WAF policy, reverse proxy/load balancer configuration, or Jira add-ons such as those by Kantega SSO

According to Microsoft, Kerberos or NTLM authentication (in Microsoft terminology, Windows Authentication) is not supported when using HTTP/2. Therefore, it is appropriate for browsers to use HTTP/1.1 when accessing a server that sends a WWW-Authenticate header to the client.

Thus, the client utilising HTTP/.1.1 in this scenario is expected.

In Atlassian's testing, when Chromium based browsers like Chrome and Edge receive this header they negotiate a new connection under HTTP/1.1 via ALPN for subsequent requests - both the request responding to the authentication challenge and subsequent requests.

Solution

If HTTP/2 is required, remove the third party solution that enforces Negotiate (Kerberos/NTLM). You may also consider another browser that re-establishes a HTTP/2 session once the authentication challenge is complete.

Other Notes

References:

• https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis

• https://bugs.chromium.org/p/chromium/issues/detail?id=685741