1858892 - Avoid auto-upgrading DNS names that resolve to local/nat/rfc 1918 addresses to https

Status: RESOLVED WONTFIX

(Core :: DOM: Security, enhancement, P5)

Description

[:Gijs (he/him)]

things like fritz.box and router.tplink.com or similar (and local "smart home" devices with names etc.) will get upgraded by the logic from bug 1812192. Ideally we shouldn't.

Comment 1

[Frederik Braun [:freddy]]

Can we resolve hosts and fallback faster if the address is local?
I have a feeling that solving this with a shared opt-out list (bug 1816449) is meaningful and interesting but probably not great for the long tail.

Comment 2

[:Gijs (he/him)]

(In reply to Frederik Braun [:freddy] from comment #1)

Can we resolve hosts and fallback faster if the address is local?
I have a feeling that solving this with a shared opt-out list (bug 1816449) is meaningful and interesting but probably not great for the long tail.

I actually wonder if the "easier" fix may for the http/https connection code that gets the DNS result to "de-upgrade" the request if the loadinfo shows it was auto-upgraded to https if the DNS result was local. How does that sound?

Comment 3

[Frederik Braun [:freddy]]

Not sure if we can go back and switch channel types (HTTPS<->HTTP) by the time we have finally resolved the address. Poking around, I found where we set the mPeerAddr in HTTPTransactionParent and wonder how that would be plumbed together.

Do you think you can help, Kershaw?

Comment 4

[Kershaw Chang [:kershaw]]

(In reply to Frederik Braun [:freddy] from comment #3)

Not sure if we can go back and switch channel types (HTTPS<->HTTP) by the time we have finally resolved the address. Poking around, I found where we set the mPeerAddr in HTTPTransactionParent and wonder how that would be plumbed together.

Do you think you can help, Kershaw?

In general, I'd like to avoid HTTP downgrade as much as possible.
Can we check the dnsSuffixList before doing HTTPS upgrade?
See bug 1582472, this suffix list is used to prevent local name resolutions using TRR.

Comment 5

[Malte Jürgens [:maltejur]]

I am unsure if this is even a issue, at least for HTTPS-First and schemeless HTTPS-First. For most local sites a HTTPS version won't be available, so we will instantly downgrade again. I have tested this with my router (fritz.box) and HTTPS-First enabled, and I almost instantly get to that site (see screen recording).

Comment 6

[Malte Jürgens [:maltejur]]

Attachment: Visiting fritz.box with HTTPS-First enabled

Comment 7

[Frederik Braun [:freddy]]

We can't easily downgrade the connection after DNS as that would require us to re-compute a lot of security header information and our heuristics should prevent this from being a persistent problem.

I'm leaning to wontfixing this, given that this has not come up as a significant issue for folks in the wild.