QUIC and Managed Browsers

Who is this for

Administrators rolling Alesia out across a managed fleet. It covers one configuration step that changes how much traffic Alesia can see on Chromium-based browsers, and explains what is and is not covered without it.

The problem

Chrome, Edge, and other Chromium-based browsers prefer HTTP/3 where a server offers it. HTTP/3 runs over QUIC, which is UDP on port 443.

Alesia's traffic inspection runs on a TCP proxy. TCP and UDP are separate transports, so QUIC connections never reach it. A browser speaking HTTP/3 to a provider API is invisible to Alesia even though the browser itself is fully configured, the certificate is installed, and the proxy is running.

This is not a gap in the certificate setup and it is not a sign of a broken install. It is the browser choosing a transport Alesia does not inspect.

The fix

Turn QUIC off in the browser by policy. The browser then uses HTTP/2 over TCP on port 443, which Alesia inspects normally.

No user-visible change. Browsing, sign-in, and the provider sites themselves are unaffected. Only the transport underneath changes, and HTTP/3 and HTTP/2 are served by the same endpoints.

macOS (Chrome and Edge, via MDM)

Deploy a configuration profile for each browser. The payload domain is com.google.Chrome for Chrome and com.microsoft.Edge for Edge.

The setting is one boolean:

Deploy it as a managed (mandatory) preference so it cannot be changed or unset from the browser's own UI.

Windows (Chrome and Edge, via Group Policy)

Import the Google Chrome and Microsoft Edge administrative templates, then set:

• Google Chrome → Network → Enable QUIC protocol → Disabled

• Microsoft Edge → Network → Enable QUIC protocol → Disabled

Either template writes the same policy: DWORD QuicAllowed = 0 under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome (or \Microsoft\Edge).

Verifying it took effect

On the endpoint, open chrome://policy (or edge://policy).

• QuicAllowed should be listed with a value of false.

• Its Source should be Platform, meaning it came from MDM or Group Policy rather than from a command-line flag or a local setting.

chrome://flags is not a substitute. A flag is per-profile, easy to reset, and disappears on browser update. It is fine for a quick manual test and wrong for a fleet.

Then confirm Alesia's own side, in the dashboard's Settings page:

• Local certificate shows Installed.

• The system extension and proxy indicators show as active.

If both sides are green and traffic to a provider still does not appear, that is a real problem and worth reporting rather than a policy issue.

Firefox and Safari

Firefox does not follow Chromium policy. Disable HTTP/3 through a policies.json file placed at Firefox.app/Contents/Resources/distribution/policies.json on macOS (or the equivalent distribution directory on Windows):

{
  "policies": {
    "Preferences": {
      "network.http.http3.enable": {
        "Value": false,
        "Status": "locked"
      }
    }
  }
}

The file must be UTF-8 without a byte-order mark. On macOS, Firefox may additionally require EnterprisePoliciesEnabled in the same file for policies to apply at all. Verify at about:policies.

Safari is not covered by this document. Safari's HTTP/3 behavior with a locally-installed root certificate has not been verified for this deployment, and administrators who care about Safari coverage should treat it as an open question rather than assume the Chromium guidance transfers.

Coverage without the policy

Alesia's network extension includes a backstop for clients that attempt QUIC: it drops the first UDP:443 connection for a source application, which prompts most clients to retry over TCP, where Alesia can see them.

This is a backstop, not a substitute for the policy:

• It depends on the client choosing to retry over TCP. Well-behaved clients do, but this is not guaranteed for every application.

• A client that does not retry is allowed through uninspected on subsequent QUIC attempts rather than being blocked, since blocking would break the application outright.

• It costs the client one failed connection attempt.

Setting the policy is the supported, deterministic path. The backstop narrows the window for clients you cannot configure, such as non-browser applications bundled with their own HTTP stack.

Coverage summary

Limits that apply regardless of QUIC

• Certificate pinning. An application that pins its provider's certificate will reject Alesia's certificate and its connections will fail rather than being inspected.

• Hardcoded or non-system trust stores. Applications that bundle their own certificate authorities do not see a root installed in the system keychain.

• Encrypted Client Hello. Where a client and server negotiate ECH, the target hostname is not visible to the proxy.

• Clients that bypass the system proxy. An application that ignores proxy settings, or that connects by IP, is not routed through Alesia at all.

None of these are affected by the QUIC policy. They are listed here so the coverage summary is read as what it is: a statement about transport, not a claim of complete visibility.