Enabling HTTP/3 support on Windows Server 2022
Published Aug 24 2021 06:00 AM 51K Views
Microsoft

Credit and thanks to Matthew Cox and Daniel Ring for implementation work

 

One of the new features Windows Server 2022 brings is native support for hosting HTTP/3 services. In this post, we will discuss how to enable it and how it can benefit web services.

 

HTTP/3 is a major overhaul of HTTP with performance and security in mind. It uses QUIC as a transport (our HTTP server, http.sys, is using msquic) to gain the benefits of eliminated head of line blocking at the transport layer. This is a significant improvement over HTTP/2 which eliminated head of line blocking only at the HTTP layer with streams that allowed a single HTTP/2 connection to replace a set of HTTP/1.1 connections. HTTP/3 also benefits from many lessons learned in HTTP/2, such as simplifying the protocol by removing prioritization.

 

The HTTP/3 standard is nearly complete; its final publication as an RFC is only waiting on formal process at this point. It is already supported by major browsers which means web services are ready to benefit from deploying it.

 

One thing to note before proceeding: these instructions presume there were no changes made to the list of enabled TLS cipher suites on the Windows Server 2022 installation. If this is not the case, consult RFC9001 (“Using TLS to Secure QUIC”) and ensure there are some cipher suites in common between the server and its expected clients. HTTP/3 is built on QUIC which requires TLS 1.3. Turning off TLS 1.3 or disabling TLS 1.3 cipher suites will result in HTTP/3 deployment failures. See “TLS Cipher Suites in Windows Server 2022” to learn how to add cipher suites and which ones are enabled by default.

 

HTTP/3 support is opt-in on Windows Server 2022 via a registry key named “EnableHttp3” with value 1 at “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters”. Running this command from an elevated prompt will create the key:

 

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters" /v EnableHttp3 /t REG_DWORD /d 1 /f

 

Once this key is set, either restart the http.sys service or reboot Windows to apply the setting.

 

It is likely the web service will need to advertise it is available over HTTP/3 as well using “Alt-Svc” headers in HTTP/2 responses (though this can also be done using HTTP/2 ALTSVC frames). This allows clients who connect over HTTP/2 to learn the service’s HTTP/3 endpoint and use that going forward. This is done by sending an HTTP/3 ALPN (“Application-layer Protocol Negotiation”) identifier with HTTP/2 responses advertising a specific version of HTTP/3 to use for future requests. Sending the ALTSVC frame  can be done by http.sys. That can be enabled by setting the “EnableAltSvc” registry key with the command below. To apply the setting, restart http.sys or reboot Windows.

 

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters" /v EnableAltSvc /t REG_DWORD /d 1 /f

 

If all goes well, the service will start serving content over HTTP/3. To ensure this is happening, use Edge to verify the protocol used to serve the web request. Right click on the page, select “Inspect”, then select the “Network” tab. If only “h2” is being used in the “Protocol” column instead of “h3”, try refreshing the page to ensure the ALPN is being honored (the first request will use HTTP/2 which will then advertise HTTP/3 support to Edge for future requests).

34 Comments
Copper Contributor

I tried this on a freshly installed instance, but I got no QUIC response, although I do see TLS 1.3 being used. I added both registry keys and restarted the server. I also cleared the browser cache and reloaded my IIS website multiple times. Any idea, how to troubleshoot this?

 

Also, on another machine I did an in-place update from 2019 auf 2022 and on this server I don't even get a TLS 1.3 connection. The browser is stuck on 1.2. Any idea, why this may happen?

Great post but windows server 2022 is already GA how odd this may sounds it has went silent to GA. 

Copper Contributor

Great article and jeej for HTTP/3 :)

 

I test with Windows Server 2022 build 20317 (per GA), and I cannot get a HTTP/3 connection. I do however have TLS 1.3. For my test I created and build a vanilla .NET 5.0 Web App (MVC) that I deployed into an application folder in my test website.

 

Of course I created both registry values mentioned and rebooted the server.

What could be wrong? Is it only in the GA version?

@tojens 

 

Update: using Windows Server 2022 build 10.0.20348 didn't change the isuse

Brass Contributor

Will Windows Server 2022 support HTTP/3+QUIC for RRAS SSTP?

Copper Contributor

Just did a test to see if IIS10 on  W2K22 with these registry additions servers up pages over QUIC but so far, no joy. Any information, pointers?

Copper Contributor

I am facing the same problems HenningKrause had faced.

After in-place upgrade form win 2019 to 202 TLS1.3 cannot be activated.  And, furthermore, I cannot bind https if I do not choose "Disable QUIC" setting.

an error is thrown stating "Incorrect function. [Exception from HResult: 0x80070001]. Aforementioned reg settings were applied and server was rebooted to no avail.  

 

cvv.png

 

 


 

Copper Contributor

@tojens

An update to my issue: it may very well be that my edge firewalls are blocking 443/UDP, I just verified I _do_ have HTTP/3 transport internally in my network. Depending on your configuration, you may also need to open the Windows firewall:

New-NetFirewallRule -DisplayName "Allow QUIC" -Direction Inbound -Protocol UDP -LocalPort 443 -Action Allow -LocalOnlyMapping $true

 Note: this is on build 20348. On build 20317 HTTP/3 still seems to be a no go.

Copper Contributor

I'm also running on build 20348, and while TLS 1.3 is working fine, QUIC is not. And I'm calling my service from the same machine, so the Firewall should not be the issue here.

Copper Contributor

@HenningKrauseDid you perform an in-place upgrade?

 

I think I have found the issue: TLS 1.3 cipher suite 'TLS_CHACHA20_POLY1305_SHA256' is required for HTTP/3, but not available in Schannel after an in-place upgrade. It's only available if you have installed the GA build directly. Or at least, so it seems.

  1. enable TLS_CHACHA20_POLY1305_SHA256: `Enable-TlsCipherSuite -Name TLS_CHACHA20_POLY1305_SHA256 -Position 0`
  2. add registry values for EnableHttp3 and EnableAltSvc
  3. verify 443/UDP traffic is allowed on the server and in your network

This worked for my set up, and I could reproduce the steps.

Copper Contributor

@JanReilink, I did a clean install of Windows. And TLS 1.3 is working. Only QUIC is not.

Copper Contributor

@JanReilink i ve did an inplace upgrade an updated to build 20384, added the mentioned cipher suite and reg keys. There is no QUIC and TLS 1.3 is still: 

 

el3c_0-1631610092357.png

 

Requested from localhost

 

If i open up google.com, QUIC ist working fine without using CHACHA POLY:

 

el3c_0-1631610703662.png

 

Copper Contributor

I have a server that was Windows Server 2019, upgraded to pre-views of Windows Server 2022, and now at RTM/GA fully patched. IIS does work over QUIC (both registry settings applied) now but I need to use Firefox or Chrome, no luck with Edge Chromium. QUIC enabled those browsers as found on Cloudflare Cloudflare HTTP/3 docs

I did not have to add any ciphers due to in-place upgrades or so.  Screenshots from the lab are below.

 

UPDATE: While chrome seemed to work it only does it once or so and fails back, so no consistent QUIC on Chrome either.

 

QUICwithIISonW2K22.jpg

Copper Contributor

FireFox indeed uses QUIC. But neither Chrome nor Edge do, although I explicitly enabled QUIC via the flags (edge://flags/#enable-quic or chrome://flags/#enable-quic).

Copper Contributor

Same here, only FF is working with QUIC and some stange warnings while sniffing the traffic with wireshark:

el3c_0-1631615869378.png

 

Copper Contributor

I can confirm Firefox uses QUIC / HTTP/3, and in my environment Chrome unfortunately doesn't. Maybe has something to do with the supported QUIC/HTTP3 draft version supported by both Chrome and MsQuic? But strange that everyone has different results with in-place upgrades, browsers, etc.

 

The following images are from the same page (internal, test - hence the self signed cert). Chrome doesn't do HTTP/3, Firefox does

Firefox, HTTP/3Firefox, HTTP/3Chrome, HTTP/2Chrome, HTTP/2

 

Update: I just disabled TLS_CHACHA20_POLY1305_SHA256, rebooted the server, and HTTP/3 is still functioning in Firefox. So guess that's not a requirement.

Copper Contributor

I have found why TL1.3 was not working on my side.

On my servers (which were upgraded from a previous version to Win 2022) I had used Nartac.com's IISCrypto tool ( a great tool by the way) to configure TLS/cipher/schannel settings. 

Then I had set the template settings on the IIScrypto tool back to "Server Defaults" . Upon reboot TLS1.3 started to work. So if you had used IIScrypto simply revert settings to defaults and then either manually disable early/unwanted TLS/ciphers/hashes or wait for new release from Nartac or use IIS'es new binding feature "Disable Legacy TLS". 

 

arslanchariyev_1-1632127642045.png

arslanchariyev_2-1632127844083.png

 

Copper Contributor

Wonderful. I'm looking forward to 2022 coming to Azure App Service.

Copper Contributor

[Playing with QUIC]
https://www.chromium.org/quic/playing-with-quic
Note that the server's certificate must be trusted by a default CA for Chrome/Chromium to accept it for QUIC.
If you are using a self-signed certificate or a certificate that is signed by a custom CA,
you need to use the --ignore-certificate-errors-spki-list command line flag to trust an individual certificate based on its spki.

Copper Contributor

I have been using QUIC on a number of Windows Server 2022 web servers since the beginning of September and they have all suffered memory leaks where non-paged memory will suddenly use all available memory on the server requiring the server to be rebooted. I have been able to trace the non-page memory leak to msquic.sys driver.


If you enable QUIC for your websites in Windows Server 2022 and get non-pooled memory leak problems, then it may well be QUIC causing the problem.

Copper Contributor

As others have reported, I'm not able to get QUIC working with Windows Server 2022 Build 20384 with IIS.

I have tried the following:

  1. added registry values for EnableHttp3 and EnableAltSvc
  2. verified 443/UDP traffic is allowed on the server and in the network
  3. optionally enabled TLS_CHACHA20_POLY1305_SHA256 (by default it is disabled. See https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-server-2022)
  4. verified that [ ] Disable QUIC in the IIS bindings is not enabled.
  5. Tested with the latest version of Firefox, Edge and Chrome from the local network.

Any suggestions would be appreciated.

Copper Contributor

Have you also enabled TLS 1.3? It doesn't seem to be mentioned above, but as well as HTTP3, TLS 1.3 needs to be enabled as it is disabled by default. You can use the following registry keys to enable TLS 1.3 in Windows Server 2022;

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3]

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]

"DisabledByDefault"=dword:00000000

"Enabled"=dword:ffffffff

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]

"DisabledByDefault"=dword:00000000

"Enabled"=dword:ffffffff


Also, use Nartac.com's IISCrypto to make sure that the following Cypher Suites are enabled;

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_CHACHA20_POLY1305_SHA256

Copper Contributor

With or without those TLS 1.3 reg keys does not make a difference for me. In FireFox it seems to work but refreshing makes it fall back to HTTP/2 (opposite of what you'd expect)., Chrome and Edge are not cooperating. It would be nice if MSFT could give a bit more guidance or info on the state of QUIC for IIS.

Copper Contributor

Are you sending an alt-svc: h3=":443"; response header to the web browser to say the website will work with HTTP3?

 

I  find you need to send this header or Chrome and Firefox will fail by default use HTTP2.

I also find that Chrome can be picky if you have already visited the website to change to HTTP3 and you may need to reboot your computer in order for Chrome to start using HTTP3 for the website.

2021-10-15_11-11-13.png

Copper Contributor

I have enabled HTTP3/QUIC on a number of Windows Server 2022 web servers, below are my notes from OneNote on how to enable it.

Please note though that I have seen non-pooled memory leaks caused by the QUIC driver, which uses up all available memory and requires a server reboot to free up memory resources. The busier the web server the more often it occurs.

 

1. Create the following registry entries;

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3]

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]

"DisabledByDefault"=dword:00000000

"Enabled"=dword:ffffffff

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]

"DisabledByDefault"=dword:00000000

"Enabled"=dword:ffffffff

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters]

"EnableHttp3"=dword:00000001

"EnableAltSvc"=dword:00000001

 2. Run the following in PowerShell to enable TLS_CHACHA20_POLY1305_SHA256

Enable-TlsCipherSuite -Name TLS_CHACHA20_POLY1305_SHA256 -Position 0

3. Reboot
 

4. Enable the following cypher suites

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_CHACHA20_POLY1305_SHA256

 

2021-10-14_15-16-24.png

 

5. Add Response header in IIS, http3

alt-svc    h3=":443"
 

2021-10-15_11-11-13.png

6. Reboot 

Copper Contributor

I will test again, but it think the docs state that there are two methods: EnableAltSvc in registry does not seem enough? Or did I misread/misinterpret what is written?

Copper Contributor

I have not tried the EnableAltSvc in the registry method so not sure what headers this would send to the browser.

Documentation from Mozilla and others I found indicated you need to send the following header which is working for me;

 

alt-svc: h3=":443"; 

Copper Contributor

By the way, I have written an HTTP / HTTPS Response Header Viewer at the link below which you can use to test what headers your website is sending which may be of use to you;

https://network-tools.webwiz.net/http-response-header-viewer.htm

 

You can use this to see if your website is sending the alt-svc: h3=":443"; header.

Copper Contributor

Set EnableAltSvc registry and check "Require Server Name Indication" on "Edit Site Binding" dialog. Browser will receive AltSvc HTTP/2 protocol message and try to connect over HTTP/3.

 

[Use ASP.NET Core with HTTP/3 on IIS]
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/http3?view=aspnetcore-6.0
IIS also supports sending an AltSvc HTTP/2 protocol message rather than a response header to notify the client that HTTP/3 is available.
See the EnableAltSvc registry key.
Note this requires netsh sslcert bindings that use host names rather than IP addresses.

Copper Contributor

I have tried setting EnableAltSvc registry and checking the "Require Server Name Indication" on "Edit Site Binding" dialogue and find that it doesn't work, at least not in Chrome, you still have to set the alt-svc: h3=":443"; header for Chrome to use QUIC. 

Copper Contributor

If you changed the settings on "Edit Site Binding" dialogue, you need to restart the OS(http.sys service).

Copper Contributor

I have tried restarting the server, but I find it is the same on all our Windows Server 2022 web servers, the only way to get QUIC working in Chrome it sending the alt-svc: h3=":443"; header.

 

We are also having to disable QUIC in the IIS bindings on busy websites, or find that msquic.sys driver uses up all available server memory. It has a non-page memory leak that means it will suddenly gobble up 10 GB of memory. This can be after happen 20 minutes after a reboot or a few days. As it is kernel memory the only way to free it up is to reboot the server.

Microsoft

Thank you to everyone for sharing their experiences. We will be publishing another post to help highlight some of the challenges each of you have run into. Please note (I need to write more about this) that the reg key enables the HTTP/3 altsvc frame; it does not add an HTTP response alt-svc header.

@webwiz just so you know, msquic is on GitHub. I know the devs who run it and they would love to hear about this memory leak you're running into: https://github.com/microsoft/msquic/issues 

Copper Contributor

If you happen to get the error below...

 

cvv.png

 

I got this error after enabling EnableHttp3 in the registry at HKLM:\SYSTEM\CurrentControlSet\services\HTTP\Parameters and I did not have a TLS 1.3 cipher suite enabled.  I noticed that if I ran 

 

Enable-TlsCipherSuite -Name TLS_CHACHA20_POLY1305_SHA256 -Position 0

 

It actually did not get enabled.  Checking with

Get-TlsCipherSuite | Format-Table -Property CipherSuite, Name

showed it was still not enabled. I had to first...

From the Group Policy Management Console, go to Computer Configuration > Administrative Templates > Network > SSL Configuration Settings.

Double-click SSL Cipher Suite Order, and then click the Enabled option. Click Ok and then switch it back to Not Configured.  After doing that the Enable-TlsCipherSuite and Get-TlsCipherSuite commands worked correctly.  Once you reboot the original site binding error should go away.

 

 

Copper Contributor

Poor naming convention can be blamed for the misunderstandings with EnableAltSvc

This really should have been named EnableAltSvcFrame. How could one not see confusion arise from this when there is more than one form of altsvc?

On a side note, the HTTP team is slacking. Is anybody at MS managing these teams? So many changes in IIS with no updates on their blog

Edit: looks like QUIC on IIS is actually kind of broken. I noticed a LOT of QUIC errors appearing in the httperr log, so I ran a script like so on the server

:start
curl https://domain.tld -k --http3 --resolve domain.tld:443:127.0.0.1
goto start


The log FILLS with QUIC errors. this is reproducible on every IIS server I have access to

Co-Authors
Version history
Last update:
‎Oct 25 2022 11:33 AM
Updated by: