Allow insecure exemption for custom local domains
Categories
(Core :: DOM: Security, enhancement, P3)
Tracking
()
People
(Reporter: gudvinr+bugzilla, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [domsecurity-backlog3])
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0
Steps to reproduce:
- Create custom TLD in local DNS server that only available in LAN
- Go to any address on any domain in that TLD
Actual results:
- Firefox tries to upgrade connection to HTTPS and inevitably fails
- After turning upgrade off Firefox marks connection as insecure
Expected results:
Firefox should not try to mark domains for internal TLDs as insecure. Since it can't decide whether or not some particular TLD local Firefox must have whitelist to make it possible including these TLDs here.
While it's possible to create self-signed certificates and distribute them across local network this is completely unnecessary for small private networks. It requires significant amount of efforts to support this with zero benefits.
But there should be a number of considerations because of possible security complications:
- If there's valid global TLD in this list it should be ignored
- If domain resolved outside of private IP range (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 and fd00::/8) it should be ignored
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•4 years ago
|
||
I'm not sure I fully understand the request in comment 0 but I think this is related to https-only-mode.
There's a dom.security.https_only_mode.upgrade_local pref that should prevent this, but maybe it doesn't work properly?
(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)
I'm not sure I fully understand the request in comment 0 but I think this is related to https-only-mode.
There's a dom.security.https_only_mode.upgrade_local pref that should prevent this, but maybe it doesn't work properly?
That looks like somewhat relevant but from information I found it only applies for IP addresses. Like when you enter "http://192.168.0.15/" in address bar.
What I am referring to is when you configure DNS server in your network that will resolve addresses in some fixed zone like ".somewhatsilly". So if you have DNS A record for "mypc.somewhatsilly" that gets resolver to "192.168.0.15" and you enter "http://mypc.somewhatsilly/" in address bar you still get warning about insecure connection even with upgrade_local=false
To clarify: case I described in my issue is what I have. I only use local DNS server for serving records in custom TLD.
I can't say if that's necessary limitation though. E.g. it is also possible to disable upgrade even if resolved domain located in .com, .it, .space, etc. And it would also solve my issue too.
I think it could lead to confusing stuff where HTTPS is enforced depending on state of VPN connection. It's not uncommon for corporate VPNs to resolve subdomains on same corporate domain to different IP because VPN pushes its DNS server address to clients.
But it could also be intended behavior and any unwanted side-effects still could be mitigated by whitelisting those domains explicitely.
|
||
Comment 5•4 years ago
|
||
I don't think we'd want to it by "hosts that resolve to RFC 1918 addresses" since that might not be enough. Maybe a domain list like ones used in other features: network.cookie.sameSite.laxByDefault.disabledHosts and security.tls.insecure_fallback_hosts for example.
It worth noting that Avahi allows to set custom TLD so it all makes more sense if you take into consideration a bug that I also filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1736456
Description
•