DNS-over-HTTPS (DoH) is a popular DNS encryption solution for traffic-level protection. Firefox began testing DoH in 2018 and DoH privacy protection has been available worldwide for users who turn it on^1. However, as the RFC 8484 stresses^2, session-level encryption has well-known weaknesses with respect to traffic analysis. And researchers proved this in NDSS2020^3.

We find a traffic analysis vulnerability of Firefox DoH implementation. As the Standards Track of DoH, RFC 8484 indicates the necessity of padding, which reduces the variety of message ("fingerprint") sizes significantly. RFC 8467 offers guidance on choosing the padding length. Among the padding strategies of RFC 8467, in consideration of security and resource consumption, multiple of 128 bytes padding for client and nearest multiple of 468 bytes for server have been taken as the de facto standard for DoH padding, such as Chromium-based browsers and built-in DoH of Windows 11.

Chrome 92.0.4515.159 (Windows 10 21H1) and Windows 11(21H2) built-in DoH 128 bytes padding example screenshots can be found in the attachment.

However, we test Firefox 91.0.2 (64-bit) and 92.0 (64-bit) for DoH padding in both Kali Linux and Windows, and we find the vulnerable padding strategy. Obviously, Firefox uses CSUBNET (Client Subnet in DNS Queries), defined in RFC 7871^5, a mechanism for recursive resolvers to send partial client IP address information to authoritative DNS name servers, resulting in short "padding" rather than multiple of 128 bytes padding.

According to the NDSS2020 paper^3, we reproduce the closed-world LOC1 attack against Firefox 91.0.2 (64-bit) in Kali Linux 2019. We collect 1500 webpages traffic of Firefox 91.0.2 (64-bit) with the DoH option from Sep. 1st to Sep. 7th, obtaining up to 16 DoH samples for every webpage. Making use of TLS record length feature and the classification code^6, we get the result averaged over 10-fold cross validation (standard deviations less than 1.2%) :

This indicates that, Firefox DoH implementation is vulnerable:

1. CSUBNET cannot replace the padding strategy.
2. Firefox users who turn DoH on are at risk of privacy, while Firefox DoH is considered as privacy protection. The adversary can only rely on DNS fingerprinting to learn which webpages are visited.
3. According to the paper^3: It is a true threat to DNS privacy even in the open-world scenario. And attackers can train a well-performing classifier with more samples.

REFERENCES

It looks like this may be a known issue we haven't gotten around to yet: see bug 1543811 comment 4

As mentioned in bug 1604591 comment 3 this hasn't been a high priority because our current settings allow DOH connections to be downgraded to regular DNS. But we do intend to turn on a stricter mode at some point.

Valentin: is that still correct? or is this paper describing something else?

That is correct. We just haven't gotten around to implementing it, although it should be relatively straightforward.
We will soon be moving to a "DoH 2.5" mode where we don't fall back for DoH connection errors, so downgrading should be a bit more difficult.
Traffic analysis will remain an issue even after implementing this, as an attacker can correlate opaque requests to a known DoH server with outgoing connections to new IP addresses.