Deactivate secure context restrictions for specific domains or tabs
Categories
(Core :: DOM: Security, enhancement)
Tracking
()
People
(Reporter: boguereport, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Steps to reproduce:
IntelliJ IDEA provides a plugin named "Projector" which allows remote access to the IDE window through a web browser.
However, by default, the service is exposed on the local network through an unsecured HTTP channel, for instance: http://192.168.0.47:8887/?token=someAccessToken
Actual results:
Firefox detects that the tab is in an unsecured context and deactivate several basic features such as copy/paste.
A warning popup is displayed. It explains how to deactivate the warning popup but not how to mark the tab as a trusted context or deactivate the feature altogether.
Expected results:
Firefox should allow to mark a tab as in a trusted context and reactivate the disabled features.
Firefox should allow to whitelist some domains (for instance in the local network) as trusted.
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' 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
|
||
Does this work in Chrome? As far as I know we follow the same specs for secure contexts, although there is some variation in the implementation.
The problem is not whether the "site" is trusted, it's that the communication channel is insecure so we can't tell that we've actually contacted the site you trust or that network attackers haven't injected code in transit (which has been seen in practice, even by big ISPs, on the open web).
Could you throw a self-signed certificate on the service, connect over https:// and then approve a certificate exception?
|
Reporter | |
Comment 3•4 years ago
|
||
Does this work in Chrome?
The behavior is the same with Chrome. The Chrome warning message also refers to the MDN documentation on secure contexts.
Could you throw a self-signed certificate on the service, connect over https:// and then approve a certificate exception?
Indeed, when I add a reverse proxy with a self-signed certificate in front of the service, there is no longer those secure context restrictions.
The problem is not whether the "site" is trusted, it's that the communication channel is insecure so we can't tell that we've actually contacted the site you trust or that network attackers haven't injected code in transit (which has been seen in practice, even by big ISPs, on the open web).
In my case, the requests only transit through a "trusted" local network. Yet, the concern is still valid. However, if I can get rid of an untrusted certificate warning, I think it would be consistent to be able to get rid of a "secure context" restriction (at my own risks).
|
|
||
Comment 4•4 years ago
|
||
We actually have this feature:
https://searchfox.org/mozilla-central/rev/4163c8f09b03871e053a61f39de020fa09e02ea9/dom/security/nsMixedContentBlocker.cpp#344
The pref is dom.securecontext.whitelist and is a comma-separated list. note the pref name may change in the future to .allowlist instead of .whitelist (bug 1607403)
|
|
Reporter | |
Comment 5•4 years ago
|
||
Thanks Daniel Veditz. I indeed missed this preference.
Description
•