How DNS HTTPS records, HTTP/3 and QUIC challenge established web security assumptions

Modern web security is built on a set of long-standing assumptions: HTTPS runs over TCP, uses port 443, and can therefore be inspected, classified, and filtered accordingly. If non-standard ports are used, those are clearly identified in the URL.

As HTTP/3 and QUIC gain adoption, these assumptions no longer always hold true.

The following example demonstrates how the same URL can lead to completely different content being delivered - without any visible indication to the user.

The same URL, different results

When accessing https://sampleattackdomain.com two browsers display very different pages:

• Chrome shows a benign informational website.
• Safari displays an alternative version that could contain highly malicious content.

From the user’s perspective, both accesses appear identical:

• the URL is unchanged
• no redirect occurs
• no non-standard port is visible

Yet the delivered content differs fundamentally.

A closer look at the network traffic

Network traces explain what is happening behind the scenes:

• Chrome connects via HTTP/1.1 or HTTP/2 over TCP port 443, following the traditional HTTPS model
• Safari establishes an HTTP/3 connection over QUIC using UDP port 3479 - a port range commonly used for collaboration and real-time communication services

Both browsers access the same hostname, but they use entirely different transport protocols and ports.

Why this matters from a security perspective

This behavior has several important implications:

First, the URL alone does not reveal which protocol or port is being used.
Users have no indication that different delivery paths are involved.

Second, UDP port ranges such as 3478–3481 are frequently permitted in enterprise environments to support applications like Microsoft Teams, Zoom, or WebRTC. These rules are often broader than intended. Hence, some standard HTTP/3 blocking rules may fail!

Third, many secure web gateways and inspection systems still lack full support for HTTP/3 and QUIC. Traffic that is neither clearly blocked nor properly inspected may pass without content analysis.

Finally, automated security scanners and reputation systems often behave like Chrome in this example. They connect via TCP port 443, observe only the benign content, and therefore classify the domain as trusted - while alternative content remains undiscovered.

Why does Safari select HTTP/3?

The deciding factor is DNS.

The browser issues a DNS HTTPS (Type 65) query when resolving the hostname.
The DNS response explicitly advertises:

• HTTP/3 support (alpn=h3)
• a non-standard port (3479)
• the same host name

Safari follows this information and establishes a QUIC connection accordingly.

Chrome behaves differently in our current tests. It also performs the DNS HTTPS query and can use the ALPN guidance for HTTP/3 discovery. However, it does not use the advertised port=3479 information to move this origin to HTTP/3 on the non-standard UDP port. Instead, Chrome continues to use the standard HTTPS port.

From a strict RFC 9460 perspective, this behavior is surprising, because the HTTPS record is specifically designed to provide endpoint metadata such as protocol configuration and alternative ports before the connection is established. From a defensive point of view, however, Chrome’s current behavior prevents this specific non-standard-port scenario from being exploited through Chrome.

Is this a browser-specific issue?

Yes, and no — in our current tests, the specific non-standard-port scenario is Safari-specific.

The underlying protocol mechanism is not Safari-specific. DNS HTTPS records are standardized and can advertise alternative endpoints, supported protocols, and ports for HTTPS origins. But the security impact depends on how individual browsers interpret and apply this information.

In our tests:

• Safari follows the DNS HTTPS record and connects to HTTP/3 on the advertised non-standard UDP port.
• Chrome also queries the DNS HTTPS record and can use the ALPN protocol guidance for HTTP/3, but it does not use the advertised non-standard port value in this test scenario.

However, our tests also showed that Chrome’s behavior can be sensitive to DNS response ordering, timing, and resolver configuration. One request may therefore end up on the classic HTTP/2 endpoint, while another request some minutes later may use HTTP/3.

This still matters from a security perspective: the HTTP/2 and HTTP/3 endpoints of the same origin may deliver different content. It can therefore be difficult to predict which exact server listener, protocol version, and transport path will be used by a particular browser in a particular environment.

If you are interested in more details, read our article "How do Browser and Website Negotiate Which HTTP Version is Used?"

Implications for enterprise environments

This example illustrates a broader challenge:

• DNS can now influence transport protocol and port selection.
• HTTP/3 can operate on arbitrary UDP ports.
• Many security architectures remain optimized for TCP-based HTTPS on port 443.
• Browser behavior around HTTP/3 discovery is not uniform.

As a result, visibility gaps may emerge - not because of misconfiguration, but because security tooling has not yet fully adapted to modern web transport mechanisms.

Practical considerations for mitigation

Organizations should consider several defensive measures:

• UDP traffic should be treated as potential web traffic, not merely as “media traffic”.
• Broad UDP allowances should be restricted to known destinations and services wherever possible.
• DNS HTTPS records (Type 65) should be included in security analysis and policy decisions.
• Browser-specific behavior should be tested explicitly; it is not sufficient to validate only one browser or one protocol discovery path.
• HTTP/3 should not simply be ignored or aimed to be generically blocked; both approaches create operational and security challenges.

Ultimately, web security solutions must be able to understand and process HTTP/3 and QUIC in the same depth as traditional HTTPS.

To make these behaviors easier to validate in real environments, we provide the SSE Testcenter. It includes controlled endpoints for testing DNS HTTPS discovery, Alt-Svc based HTTP/3 upgrades, HTTP/3 availability on non-standard UDP ports, and gateway behavior when multiple protocol paths are available for the same hostname.

Conclusion

HTTP/3 is no longer an experimental protocol.
It is supported by all major modern browsers, and a wide range of web servers support it too. This creates opportunities for attackers to hide alternative delivery paths from scanners, reputation systems, or security controls that still focus primarily on TCP-based HTTPS.

Security strategies that focus exclusively on TCP port 443, or merely aim to block HTTP/3 traffic, may lose visibility into significant parts of modern web traffic and risk creating bypass opportunities. Adapting security architectures to these changes is essential to maintain consistent protection.