1604591 - TRR (DNS over HTTPS) does not use HTTP2 Padding, revealing some DNS over HTTPS Detail

Status: RESOLVED DUPLICATE of bug 1543811

(Core :: Networking: DNS, defect, P2)

Description

[jullrich]

I discovered this issue by collecting traffic from Firefox 71 using tcpdump, and analyzing it with Wireshark. No specific configuration is necessary other than enabling DoH / TRR . I used the default Cloudflare DNS over HTTPS endpoint.

Firefox does not take advantage of HTTP2 or TLS padding to obscure the size of requests. As a result, it is pretty easy to count the number of DNS requests and responses, or even narrow down the content of the requests and responses by observing the packet sizes of the traffic between the client and the resolver. HTTP2 padding (see sections 6.1 and 10.7 of RFC7540) can be used to avoid this issue.

Comment 1

[jullrich]

Attachment: doh.pcap

attaching a file with DNS over HTTPS traffic collected between Firefox and Cloudflare. All queries can be identified by their TCP payload length of 59 and all responses by the TCP payload length of 31. Part of the reason is that the headers are sent in their own packet, and the actual DNS payload is sent in a second packet. Since all query and response, HTTP2 headers have the same content, the length is the same for these packets.

The length of the hostname being queried can be approximated by taking the TCP payload length - 68. For example, The first query for example.com (packet #14) as a TCP segment length of 79. "example.com" is 11 bytes long. Packet # 27 is a query for "push.services.mozilla.com". Its TCP segment length is 93 (93-68=25 which is the length of push.services.mozilla.com).

Comment 2

[:Gijs (out for now; he/him)]

Dana, do you know what our options are here? Unsure if there's other DoH folks around who need to see this and aren't on PTO until the new year.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

We've known about this one for a while now - see bug 1543811.
We haven't worried about it too much thus far since it's trivial to block or downgrade TRR to regular DNS.
Once we start shipping mode3, I suppose this gets a slightly higher priority.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler]]

I suppose that's our answer for now, unless Wayne wants to add anything.

Comment 5

[Wayne Thayer]

(In reply to Valentin Gosu [:valentin] (he/him) [PTO until Jan 6th] from comment #3)

We've known about this one for a while now - see bug 1543811.
We haven't worried about it too much thus far since it's trivial to block or downgrade TRR to regular DNS.
Once we start shipping mode3, I suppose this gets a slightly higher priority.

This issue allows a passive attack that (unlike a downgrade) would be undetectable by a user who thought they were receiving the benefits of DoH, correct? If so, I'd argue that this should have a higher priority but otherwise agree with the response.

Comment 6

[jullrich]

The issue is IMHO that the point of DoH is privacy from entities that are able to observe the traffic to a recursive resolver. This issue doesn't completely reveal the query, but it significantly limits the possible solutions. Not a huge deal, but something that should probably be fixed with some kind of padding in the future. Some form of padding, either via a DNS option (RFC 7830 and 8467) or via HTTP2 (RFC 7540 Section 6.1) should do the trick with a slight preference to DNS padding. The DoH resolvers need to pad the responses as well to fully mitigate this problem, so this isn't just a Firefox issue.

Thanks for looking into this and responding so quickly. Sorry I didn't see the bug report mentioned above earlier.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:mayhemer, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Valentin Gosu [:valentin] (he/him)]

I'm going to make this a P2.
Hopefully I can get to it soon.

Comment 9

[Honza Bambas (:mayhemer)]

Thanks, Valentin!