1646902 - DNS-over-HTTPS Downgrade Attack

Status: UNCONFIRMED

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

Description

[qhuang6]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36

Steps to reproduce:

In our recent project about DNS-over-HTTPS (DoH), we found that Firefox may subject to DoH downgrade attacks when using the opportunistic mode.
We assume two types of adversaries based on their capabilities of manipulating network packets, called in-path attacker and on-path attacker. In-path attacker has the ability to not only sniff but also change all passing through network packets. On-path attacker is only able to inspect packets and inject new packets. An in-path at-tacker could be a network gateway while an on-path attacker could be another user sharing LAN with the victim.
DNS Spoofing: On-path attacker targets DoH URI resolution, who re-places DoH resolver’s IP in reply by an unreachable IP.
DNS Interception: In-path attacker targets DoH URI resolution, who blocks the queries looking for the IP of DoH resolver.
TCP Reset Injection: On-path attacker targets DoH traffic, who disrupts DoH connection by sending forged TCP reset packets to the victim.
TCP Interception: In-path attacker targets DoH traffic, who blocks all DoH packets between victim and DoH resolver.

Actual results:

If DoH URI resolution or DoH traffic is intercepted by a MitM attacker (via DNS cache poisoning, TCP RST attack, etc), the browser will fallback to normal DNS without any notification to the users. Thus the DNS traffic could be further manipulated by the attackers and censors.

Expected results:

We hope this information could be useful for your product development. We wonder if it's possible for you to tackle this problem. Here are our suggestions. 1) DoH protocol could be improved. 2) at least, users could be notified when DoH is not working just like the indicator of HTTPS certificate.

Comment 1

[Johann Hofmann [:johannh]]

Dragana, Valentin, can you take a look?

Comment 2

[Dragana Damjanovic [:dragana]]

I am not sure this is a security issue. This is a known problem, since DoH is turned on in the fallback mode (there is also no-fallback mode (mode3)).
We will look into better visibility of DoH problems.

Comment 3

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

These issues are well known. I don't think this needs to stay hidden. Going forward we will try to address some of these.

Comment 4

[Nhi Nguyen (:nhi)]

I don't think this needs to stay hidden. Dan, could you please assess and lift the restriction if you agree?

Comment 5

[Daniel Veditz [:dveditz]]

Yes, this is the point of opportunistic mode. It's expected to fail at times (perhaps maliciously) but still provides a benefit against passive observation most of the time. Shipping a stricter mode was deemed impractical at this time (too many unhappy users) so the choice was between nothing or the opportunistic mode with known active attacks. There are even some canary values that will intentionally disable DoH entirely.