https-only mode exception for local addresses reportedly does not work for 172.16/12
Categories
(Core :: DOM: Security, enhancement, P3)
Tracking
()
People
(Reporter: freddy, Unassigned)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [domsecurity-backlog2])
A user reported that the exception for local addresses does not work for their internal network addresses. The discussion is at https://lobste.rs/s/splkqh/set_up_https_by_default_your_browser#c_s3vanq.
What should happen:
Navigating to local resources should not cause a warning with HTTPS only mode and should just work
What actually happens:
The user is seeing the warning dialog.
|
Reporter | |
Comment 1•3 years ago
|
||
What should happen:
Navigating to local resources should not cause a warning with HTTPS only mode and should just work
As long as I am reading nsHTTPSOnlyUtils::LoopbackOrLocalException() right.
|
|
Reporter | |
Updated•3 years ago
|
|
||
Comment 2•2 years ago
|
||
172.16/12 are not "local" (loopback) addresses, they are RFC 1918 "private" addresses. The local exception--granted because there's no network traversal and therefore no MITM risk--does not apply to private addresses which do require network connections. The bug summary "https-only mode exception for local addresses reportedly does not work for 172.16/12" is working as designed.
But raw private addresses do pose a usability problem for https-only. Public Certificate Authorities aren't allowed to issue certs to raw IP addresses, and doubly so "private" addresses which are not at all unique. Reaching those sites securely is always problematic because there will need to be some kind of exception. The sites might use a certificate issued by a local CA, which the user might have installed -- the only case where an upgrade will go smoothly. The user may also have visited the site with a self-signed cert in the past and added an exception, and after that an upgrade will also go smoothly. Or maybe there's no cert at all and the upgrade will fail.
Could we give them an exception? sure, but what about the "Secure connection or nothing!" folks. Currently "HTTPS-only" caters to the latter: if we can't reach the site securely then you get to choose whether to grant an exception or not. "HTTPS-first" caters to the "just work" crowd and is pretty much the behavior you're asking for.
If our current plan is to eventually ship "https-first" by default and leave "https-only" as an opt-in for the hard-core "HTTPS Everywhere!" crowd this bug is probably wontfix, or maybe "already works" for what most people want (if only we exposed the pref for https-first).
|
|
Reporter | |
Comment 3•2 years ago
|
||
I think we can leave that WONTFIX. HTTPS-Only should remain the stricter option (with UI opt-outs). HTTPS-First already has a fallback anyway.
Description
•