Setting Up and Running Your Own QUIC Server

QUIC, or Quick UDP Internet Connections, is a modern transport layer network protocol designed by Google, aiming to make web applications faster, more secure, and more efficient. If you’re looking to delve into the world of QUIC and understand how it operates, setting up your own Quic Server is an excellent starting point. This guide will walk you through the process of building, configuring, and running a basic QUIC server using readily available tools from the Chromium project and QUICHE.

Build the QUIC Client and Server Binaries

To begin, you’ll need to compile the QUIC server and client binaries. These are conveniently provided within the Chromium source code and QUICHE (QUIC HE). Assuming you have already downloaded the Chromium source code as per the Chromium project’s guidelines, you can proceed to build the necessary binaries using the Ninja build system.

ninja -C out/Debug quic_server quic_client

This command will generate several binary targets, including:

quic_server: A basic QUIC server implementation for testing, located in //net/tools/quic/quic_simple_server_bin.cc. Note that its proxying capabilities may have unresolved issues.
quic_client: A corresponding QUIC client, found at //net/tools/quic/quic_simple_client_bin.cc.
epoll_quic_server: An enhanced QUIC server from QUICHE, similar to quic_server but with support for proxying via CONNECT, including CONNECT-UDP. This is specifically for Linux systems due to its reliance on epoll(7).
epoll_quic_client: The QUICHE-based client counterpart to epoll_quic_server, also Linux-specific.
masque_server: A specialized server in QUICHE designed solely for proxying via MASQUE (CONNECT-UDP, CONNECT-IP, or CONNECT-ETHERNET), excluding standard CONNECT tunnels.
masque_client: A versatile client capable of fetching URLs over QUIC in a CONNECT-UDP tunnel or establishing tun (CONNECT-IP) or tap (CONNECT-ETHERNET) tunnels.

Prepare Test Data from www.example.org

For testing purposes, the server implementations can serve content cached on disk. This data needs to be in a specific format, typically generated using wget -p --save-headers.

To acquire a local copy of www.example.org, execute the following commands:

mkdir /tmp/quic-data
cd /tmp/quic-data
wget -p --save-headers https://www.example.org

After downloading, you need to manually adjust the index.html file by editing its headers:

Remove if present: Transfer-Encoding: chunked
Remove if present: Alternate-Protocol: ...
Add: X-Original-Url: https://www.example.org/

These modifications ensure the cached data is correctly served by your QUIC server.

Generate Certificates for Your QUIC Server

To operate a QUIC server, a valid SSL/TLS certificate and a private key in PKCS#8 format are essential. If you don’t already possess these, you can utilize provided scripts to generate them.

cd net/tools/quic/certs
./generate-certs.sh
cd -

These scripts will create a certificate and key for www.example.org in net/tools/quic/certs/out/, valid for a brief three-day period.

Additionally, the script generates a CA certificate (net/tools/quic/certs/out/2048-sha256-root.pem). For your system to trust this certificate during validation, you must add it to your operating system’s root certificate store. For Linux users, detailed instructions are available here. This step is crucial for quic_client to properly verify the server’s certificate.

Alt text: Diagram showing steps to generate SSL/TLS certificates for QUIC server, including key generation, certificate signing, and CA root certificate installation for trusted connections.

It’s important to note that Chrome/Chromium browsers have specific handling for QUIC certificates and do not inherently trust custom CAs for QUIC connections. Therefore, alongside adding the root certificate to the system store, you may need to use the --ignore-certificate-errors-spki-list=.. flag and provide the certificate’s SPKI (Subject Public Key Info) to allow Chrome/Chromium to accept your custom certificate.

You can generate the SPKI using OpenSSL with the following command:

openssl x509 -noout -pubkey

Run the QUIC Server and Client with Cached Data

With the binaries built, test data prepared, and certificates generated, you can now run your QUIC server. Execute quic_server, directing it to the cached www.example.org content and the generated certificate and key files:

./out/Debug/quic_server 
  --quic_response_cache_dir=/tmp/quic-data/www.example.org 
  --certificate_file=net/tools/quic/certs/out/leaf_cert.pem 
  --key_file=net/tools/quic/certs/out/leaf_cert.pkcs8

Subsequently, you can use quic_client to request content from your QUIC server:

./out/Debug/quic_client --host=127.0.0.1 --port=6121 https://www.example.org/

If you use the default server port (6121), ensure you specify the client port, as it defaults to 80. Furthermore, if your machine uses multiple loopback addresses (like both IPv4 and IPv6), you might need to specify a particular address.

For servers with untrusted certificates, utilize the --disable_certificate_verification flag on the client. If the certificate is trusted but chains to a user-installed CA, use --allow_unknown_root_cert.

Important: Both quic_client and quic_server are primarily intended for integration testing and are not optimized for high-scale performance.

To test with Chrome, use the following command, ensuring the server’s certificate is trusted by a default CA or using SPKI pinning:

chrome 
  --user-data-dir=/tmp/chrome-profile 
  --no-proxy-server 
  --enable-quic 
  --origin-to-force-quic-on=www.example.org:443 
  --host-resolver-rules='MAP www.example.org:443 127.0.0.1:6121' 
  https://www.example.org

Remember, for Chrome/Chromium to accept a certificate for QUIC, it must be trusted by a default CA. For self-signed or custom CA certificates, use --ignore-certificate-errors-spki-list with the certificate’s SPKI. Trusting a custom CA directly in Chrome via flags is not supported. For MITM proxies, QUIC should be blocked, and TLS interception should be used instead.

Proxying Requests with Your QUIC Server

To configure proxying using CONNECT with your QUIC server:

./out/Default/epoll_quic_server 
  --mode=proxy 
  --connect_proxy_destinations=google.com:443 
  --certificate_file=net/tools/quic/certs/out/leaf_cert.pem 
  --key_file=net/tools/quic/certs/out/leaf_cert.pkcs8

For Chrome configuration to utilize this proxy, ensure the root certificate is in the cert store and the leaf certificate’s SPKI is correctly set:

out/Default/chrome 
  --user-data-dir=/tmp/chrome-profile 
  --host-resolver-rules='MAP www.example.org 127.0.0.1' 
  --proxy-server=quic://www.example.org:6121 
  --origin-to-force-quic-on=www.example.org:6121 
  --ignore-certificate-errors 
  --ignore-certificate-errors-spki-list="${SPKI}"

Flags like --ignore-certificate-errors, --ignore-certificate-errors-spki-list, and --origin-to-force-quic-on are necessary, along with the root certificate in the system’s certificate store, to prevent certificate validation issues.

Troubleshooting Your QUIC Server

If you encounter issues while setting up or running your QUIC server, try launching the server or client with the --v=1 flag. This will increase the logging verbosity, providing more detailed output that can often help identify the root cause of problems. Increased logging is invaluable for diagnosing configuration or runtime errors.

By following these steps, you should be able to successfully set up and experiment with your own QUIC server, gaining practical experience with this emerging network protocol.