SMB over QUIC Testing Guide – Part I

Introduction

QUIC is a recent secure networking transport on top of UDP. This and TLS 1.3 form the basis for HTTP/3.
It has many benefits compared to HTTP/2 over TCP with TLS 1.2 or TLS 1.3. I have written about SMB over QUIC before in QUIC, hurry up, where I position TLS 1.3, HTTP/3, and QUIC in Microsoft’s operating systems. I invite you to read that article for my musings on this subject.

No matter who you are and what you do in IT, you will be using QUIC in some shape or manner. QUIC is very young, and we are only at the beginning of its journey in development, evolution, and adoption. Next to HTTP/3, we see an interest in using QUIC for many other use cases such as DNS and SMB. In this article, I will be looking at SMB over QUIC and why to use it.

SMB over QUIC is available in Window Server 2022 Azure Edition (in preview at the time of writing) and can be deployed in Azure as well as on Azure Stack HCI. I think they should make it available on any Windows Server 2022 edition, but that is my opinion. You can leverage preview versions of Windows 10, Windows 11 (Windows Insider, dev channel), or Window Server 2022 Azure Edition as SMB over QUIC clients.

SMB over QUIC

Advantages

SMB over QUIC provides security in 2 ways. It prevents server spoofing as the server certificate proves you are connecting to the intended host. Secondly, TLS 1.3 always encrypts SMB over QUIC.

While IT blocks port 445 in the majority of cases, port 443 is typically open. That means that SMB over QUIC via UDP/443 should work in the majority of cases. Google seems to have a very high success rate (+/- 93%) with its QUIC implementations. That number indicates that UP/443 indeed works “as is” in the majority of environments.

Downsides

There are some downsides compared to SMB over TCP/445. For one, the performance is not as good as it is with SMB encryption. Part of this is because there is no hardware offload support.

Since the client cannot reach a Key Distribution Center (KDC) over the internet, Kerberos is not an option, as there is no direct line of sight to a domain controller. So, authentication defaults to NTLM. The good news is that the TLS 1.3 connection encrypts/tunnels the NTLMv2 exchanges. But we do not have to use NTLMv2. By configuring a KDC proxy service, we enable the use of Kerberos authentication.

Another downside is that the TLS encryption is “machine to machine” and not “user to machine.” For some, that might be an issue.

Use cases and setting them up

The eye-catching use case for SMB over QUIC is securely accessing files shares over the internet without needing any VPN. The magic of QUIC is UDP over port 443 lies in the fact that it is always secure by design thanks to certificates and TLS 1.3. That makes sense; SMB over TCP/445 is not readily usable over the internet. Port 445 is more often blocked than allowed in the firewall, and for good reasons. Secure usage of SMB in a public environment is not a walk in the park. It means that you cannot use it to connect to cloud file shares and without needing VPNs or REST-based file access.

From the moment I learned about SMB over QUIC, being the curious and nosey MVP, I was interested in how this works and how to set this up. So, I dove into the lab as soon as it was available in preview, and I will share my learnings with you.

SMB over QUIC integration in the client and the server

The SMB Protocol Stack integration

SMB sits on top of the QUIC stack. In regards to SMB features, this makes very little difference. Multichannel will still work as you have learned to expect. No SMB encryption or signing is required because, by default, SMB over QUIC is always encrypted (TLS 1.3). SMB over QUIC will use the server certificate to ensure there is no server spoofing attack. For secure connections, the SMB connection settings are negotiable. By default, the SMB over QUIC uses the transport layer security/encryption (TLS 1.) even when we enabled SMB encryption on a file share. The SMB client must append the negotiation context ID=0x0006 to learn if the transport layer security is accepted. We can, however, select to use SMB encryption on top of the TLS 1.3 encryption of QUIC. Note that QUIC always uses TLS 1.3 encryption. QUIC does not alter SMB authentication in any way.

SMB over QUIC process from the client-side

• The client [1] opens \\Demo-vm-01\smb-quic-demo [2]
• The client resolves the IP address of our file server via DNS [3]
• The client attempts to connect using TCP/IP [4] and QUIC [5] in parallel. That is because the client does not know if the server supports QUIC, TCP, or both. As a result, the client needs to attempt both. At the moment, TCP gets a slight head start to establish the connection. Doing so provides the best experience for people inside the corporate network while still offering transparent QUIC connectivity when the users are not.
• The client SMB multichannel will negotiate interfaces with the server and will select the most optimal scenario. Whether RDMA [6] is available or not will be detected via multichannel. Note that there is no RDMA support for QUIC at the moment of writing. I can, however, see this happen in the future as I see no reason why RDMA and QUIC would not be a “better together” story. Remember that RoCEv2 used UDP, so RDMA is not just about TCP/IP.
• The client will use TCP/IP or QUIC depending on what connection established first
• The client starts sending/receiving data over SMB [7].

Note that if QUIC is not available for some reason, TCP/445 is always there to save the day unless it has been explicitly disabled or cannot work (no connectivity over TCP/445).

SMB over QUIC process from the server-side

• The server opens endpoints listening on UDP/443, not only TCP/445 [1]. By default, the server starts both TCP/IP and QUIC listeners. However, you can configure the server to start only TCP/IP or only QUIC listeners selectively. It does not have to do both.
• The server receives new QUIC connection requests [2] from the SMB clients
• The server finds the certificate [3] for the new QUIC connection
• The server accepts the connection, and authentication takes place [4].
• The server sends/receives data over SMB over QUIC [5]
• Note that if QUIC is not available for some reason, TCP/445 is there unless explicitly disabled [6].
• Whether RDMA [7] is available or not will be detected via multichannel. Note that there is no RDMA support for QUIC at the moment of writing. I can, however, see this happen in the future as I see no reason why RDMA and QUIC would not be a “better together” story. Remember that RoCEv2 used UDP, so RDMA is not just about TCP/IP.
• The server starts sending/receiving data via SMB [8]

Note that if QUIC is not available for some reason, TCP/445 is always there to save the day unless it has been explicitly disabled or cannot work (no connectivity over TCP/445).

Installing an SMB over QUIC Server

For our lab, we are deploying two Windows Server 2022 Datacenter Azure Edition Virtual machines in Azure. We will use one as an SMB server and one as an SMB client. During the early days of the preview, you only had three regions where it was available (West Central US, South Central US, or North Europe). Twenty more came online a week later, and now it should be available in all. By the time you read, this it might very well be out of preview and generally available.

Ensure you join your Windows Server 2022 Datacenter Azure Edition file server and the client to your Active Directory domain.

The file server must have access to at least one domain controller for authentication. Heck, even in the lab, I have 2. There is no need to allow any access from (gulp!) or to the internet from your domain controllers.

Firewall

On the Windows Firewall, the rules exist to allow SMB traffic over both TCP/455 and UDP/443. You can block TCP/445 to force UDP/443 (QUIC) for testing.

Configure your 3^rd party firewall(s) to allow access from the internet to adding a firewall rule to allow inbound traffic for UDP/443. By blocking inbound traffic for TCP/445 to the file server, you will force SMB over QUIC. That might not be what you want on the internal firewall, but it is probably already in place on the internet-facing firewall. On an edge firewall, you block TCP/445 in and outgoing, which is fine, except for specific rules for access to Azure file shares, for example.

However, for QUIC to work for telecommuters and road warriors, you will want to allow UDP/443. For a discussion around the security impact on this, see QUIC, hurry up.

Today, any decent security appliance vendor should plan to recognize and deal with QUIC instead of classifying it as “Generic UDP” traffic.

Configuration options on the SMB Server & Client

SMB client Settings

While blocking TCP/445 can help test SMB over QUIC when using windows explores to access the shares, you can also enforce QUIC via NET USE or PowerShell commands.

The above forces the mapping to use QUIC.

Disabling the certificate check is OK for testing or internal use, but you should never use this on internet-facing servers.

Below is an example

Via Get-SMBMapping, you can look at the TransportType used (QUIC or TCP) alongside other properties.

We now take a look at the SMB client configuration with Get-SmbClientConfiguration

As said before, TLS 1.3 provides encryption for SMB over QUIC, so you usually do not need SMB encryption. That’s why the default value for this setting is false. If you need it to enable SMB encryption, you can set it to True.

The default value for SkipCertificateCheck is false. You usually do not want to disable this, but for testing. It can come in handy.

SMB client Settings

When we look at the SMB server configuration options Get-SmbServerConfiguration, we also find some settings related to QUIC.

• DisableSmbEncryptionOnSecureConnection
• RestrictNamedPipeAccessViaQuic
• EnableSMBQUIC

These are pretty much self-explicatory, and you can change them via PowerShell. The default values are all “True” and make sense. We do indeed want QUIC enabled and restrict named pipe access over via QUIC. When using QUIC, the communications go over TLS 1.3, so SMB encryption is not enforced on top of that by default.

You can change these settings with PowerShell, as shown below.

Certificate usage guidelines

When it comes to the certificate requirements, the recommendations will not come as a surprise. Avoid using self-signed certificates. Yes, even in the lab, if possible. I run a permanent Active Directory Certificate services Public Key Infrastructure (PKI) in the lab. It also helps maintain my skillset around PKI technologies. For me, the effort is worth it.

Use only certificates from a privately or publicly trusted root certification authority. That means a commercial certificate, “Let’s Encrypt,” or your own Public Key Infrastructure.

The Certificate Authority-issued certificate will have the following properties:

• Key usage: digital signature, non-repudiation
• Purpose: Server Authentication (EKU 1.3.6.1.5.5.7.3.1)
• Signature algorithm: SHA256RSA (or greater)
• Signature hash: SHA256 (or greater)
• Public key algorithm: ECDCA_P256. You can still use RSA with at least 2048 length but hey, go modern.
• Subject Alternative Name (SAN): Every DNS name entry for each fully qualified DNS name used to reach the SMB server
• Subject: CN=” Name” (whatever makes sense, but it cannot be empty)
• Private key included: yes

Creating an SMB over QUIC certificate template

Open the Certificate Authority MMC, select “Certificate Templates,” right-click and select “Manage.” We duplicate the computer template and adapt it to the needs and requirements for an SMB over QUIC certificate.

First of all, set the compatibility settings to the latest of the greatest to get the most modern features and the best security.

On the “General” tab, the second thing we do is fill out the template display name and name to identify it easily. We also select to publish the certificate in Active Directory.

In the “Request Handling” tab, set the purpose for the certificate to “Signature.” Click OK on any warning you’ll see there.

On the “Cryptography” tab, we set the provider category to Key Storage Provider, and for the algorithm, we select ECDSA_P256. That is a bit more modern than RSA and also a bit faster. Finally, set the request hash to SHA256.

On the “Extensions” tab, go to “Application Policies” and remove client authentication.

Via the security tab, you can set the permissions as to who and what is allowed. For this purpose, I can leave it at the defaults (domain computers are allowed to enroll).

On the “Subject Name” tab, we select “Supply in the request.” Click “OK” on any warning you get. We need to set custom names for our SMB over QUIC file server(s), so we elect to supply them manually. Tick the box to “Use subject information from existing certificates for autoenrollment renewal requests.”

Click “OK.” That’s it! We created our new SmbOverQuick certificate template. We now publish it so we can enroll our server to get one.

That’s it. You will now have the SmbOverQuic certificate template available to you when requesting certs for your certification authority.

Get a certificate for the SMB over QUIC file server

On the file server, launch the local computer certificate store. Using certlm from an elevated command prompt is the fastest way to get there.

Now right click on “certificates” in the “Personal” store. Choose “All tasks” and select “Request New Certificate.”

Click through the “Before You Begin” message and select “Active Directory Enrollment Policy.” Click “Next”

Find and select the SmbOverQuic certificate template we created earlier and click on the hyperlink to enter the custom information.

We set the subject name to a type of “Common Name” and enter a subject name for the cert. I chose the server’s name “W2K22Azure”.

Under alternative names, I choose a type of “DNS” and enter both the hostnames and the FQDN names that I want to use for this file server internally. These are W2K22Azure,W2K22Azure.datawisetech.corp,fsquic,fsquic.datawisetech.cor. I also enter the external domain name quicedge.datawisetech.com. I went overboard a bit for further testing.

Click “Apply” and “OK”

Click on enroll and wait a moment to see whether this was successful.

Cool, we now have a cert on the file server to configure SMB over QUIC!

That’s is for now. In part II of this article, we will use our knowledge and preparations done here to build a fully working SMB over QUIC solution.