Closed
Bug 1063730
Opened 10 years ago
Closed 10 years ago
Screensharing (windows, apps) should only be allowed on https: origin sites
Categories
(Core :: WebRTC, defect)
Core
WebRTC
Tracking
()
RESOLVED
FIXED
mozilla35
People
(Reporter: jesup, Assigned: ekr)
References
()
Details
Attachments
(1 file)
(deleted),
patch
|
geekboy
:
review+
mt
:
review+
lmandel
:
approval-mozilla-aurora+
lmandel
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
As part of our (and the IETF's/W3C's) continuing push to put new web services on secure connections always, and to avoid a class of hijack/MITM/landing-page hijack attacks, we should limit screensharing not just to sites in the whitelist, but sites that are also loaded over https (like the way we restrict "Always allow" for camera/mic to https sites.)
Per bug 1049583, sites with landing pages that aren't https/HSTS are prone to DNS poisoning/hijacking/AP-based MITM/etc. (and the sites proposed aren't HSTS/etc, at least not the landing pages for those domains, per gcp)
We would want this in 33 probably.
Comment 1•10 years ago
|
||
Here's an example of one that matches the whitelist:
https://ciscosales.webex.com/
It has a cert verified by VeriSign so it should pass this test. I would be interested to know if it does not.
Reporter | ||
Comment 2•10 years ago
|
||
(In reply to Ethan Hugg [:ehugg] from comment #1)
> Here's an example of one that matches the whitelist:
>
> https://ciscosales.webex.com/
>
> It has a cert verified by VeriSign so it should pass this test. I would be
> interested to know if it does not.
Does it support HSTS? Otherwise, someone entering http://ciscosales.webex.com can get redirected before they get to the Cisco HTTPS URL.
Comment 3•10 years ago
|
||
For anything that is operating off the whitelist, this is definitely worthwhile. We should only permit access to the whitelist off a strongly authenticated origin. But that's more about protecting the integrity of the persistent permission grant.
I'm not sure that we have a general policy basis to restrict services to secure origins though. Discussion about WebCrypto indicates that there is some resistance to following Chrome's principled position on this.
I don't think that we have an HSTS issue here given the nature of the feature. Hijacking the http:// version of the origin isn't going to provide any advantage to an attacker if we isolate the persistent permission to the authenticated origin.
Comment 4•10 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #2)
> (In reply to Ethan Hugg [:ehugg] from comment #1)
> > Here's an example of one that matches the whitelist:
> >
> > https://ciscosales.webex.com/
> >
> > It has a cert verified by VeriSign so it should pass this test. I would be
> > interested to know if it does not.
>
> Does it support HSTS? Otherwise, someone entering
> http://ciscosales.webex.com can get redirected before they get to the Cisco
> HTTPS URL.
OK, I checked and it does not give a "Strict-Transport-Security" value in the response header. We could probably fix that if required.
Comment 5•10 years ago
|
||
(In reply to Ethan Hugg [:ehugg] from comment #4)
> OK, I checked and it does not give a "Strict-Transport-Security" value in
> the response header. We could probably fix that if required.
It's not required for this, but you might like to consider it for other reasons.
Comment 6•10 years ago
|
||
(In reply to Martin Thomson [:mt] from comment #3)
> I'm not sure that we have a general policy basis to restrict services to
> secure origins though.
I want to second this. While I believe we should strongly push for the *default sites we ship* to have proper HSTS/HTTPS safeguards, and thus set the good example and not undermine our pre-set whitelist, this is something quite different from outright blocking the feature to anyone without an HTTPS cert.
>I don't think that we have an HSTS issue here given the nature of the feature. Hijacking the http://
>version of the origin isn't going to provide any advantage to an attacker if we isolate the
>persistent permission to the authenticated origin.
It circumvents the whitelist. If you don't see a problem with that, then why have the whitelist in the first place?
Comment 7•10 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #6)
> >I don't think that we have an HSTS issue here given the nature of the feature. Hijacking the http://
> >version of the origin isn't going to provide any advantage to an attacker if we isolate the
> >persistent permission to the authenticated origin.
>
> It circumvents the whitelist. If you don't see a problem with that, then why
> have the whitelist in the first place?
It doesn't circumvent the whitelist if the whitelist is only checked for https:// origins. Which is exactly what I was proposing:
> We should only permit access to the whitelist off a strongly authenticated origin.
Comment 8•10 years ago
|
||
I think we just went full circle. The whitelist is the *ONLY* way to use screensharing. If it's linked to HTTPS, then we've just decided that you either use HTTPS or you don't get to use screensharing - at all. (The discussion on this is ongoing on dev-platform as far as I can tell)
Maybe this is expected and intended but I want to avoid conflation between the "persistent permissions" thing requiring HTTPS and "being able to use the feature at all" requiring HTTPS.
Comment 9•10 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #8)
> I think we just went full circle. The whitelist is the *ONLY* way to use
> screensharing. If it's linked to HTTPS, then we've just decided that you
> either use HTTPS or you don't get to use screensharing - at all. (The
> discussion on this is ongoing on dev-platform as far as I can tell)
There's two things here:
1. What we do now, which is limited access based on a whitelist.
2. What we do in general.
The whitelist is not an end state, it's a temporary condition only. It's that way because we only have full-desktop sharing, and that opens a massive security vulnerability.
What I'm talking about is specifically related to the whitelist, as an embodiment of a persistent, origin-bound permission. As such, if we can't strongly authenticate the origin, we should not permit the use of screensharing. That true now, and in the future (and there is support for that position in the various standards groups.) In the end state, I don't see any reason to prevent one-off use on unsecured origins if that means deviating from what the W3C Media Capture Task Force has defined.
If we can change their minds, that's different.
Reporter | ||
Comment 10•10 years ago
|
||
(In reply to Martin Thomson [:mt] from comment #9)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #8)
> > I think we just went full circle. The whitelist is the *ONLY* way to use
> > screensharing. If it's linked to HTTPS, then we've just decided that you
> > either use HTTPS or you don't get to use screensharing - at all. (The
> > discussion on this is ongoing on dev-platform as far as I can tell)
>
> There's two things here:
>
> 1. What we do now, which is limited access based on a whitelist.
>
> 2. What we do in general.
>
> The whitelist is not an end state, it's a temporary condition only. It's
> that way because we only have full-desktop sharing, and that opens a massive
> security vulnerability.
I agree the whitelist is not an endstate. What I don't know yet is a reasonable way to provide a) what people want, with b) enough security to avoid people machine-gunning themselves in the knees (security-wise), given c) the typical person using this.
One correction: we have a) full-screen sharing (most risky, and most commonly wanted), b) window sharing (also common, and also commonly the window they want to share is from a browser, c) app sharing (effectively the same as window, plus exposing popups).
> What I'm talking about is specifically related to the whitelist, as an
> embodiment of a persistent, origin-bound permission. As such, if we can't
> strongly authenticate the origin, we should not permit the use of
> screensharing. That true now, and in the future (and there is support for
> that position in the various standards groups.)
Agreed
> In the end state, I don't
> see any reason to prevent one-off use on unsecured origins if that means
> deviating from what the W3C Media Capture Task Force has defined.
I'd also state that users will have no concept of the security risks they're adding to themselves by allowing a sharing request from an un-authenticated site. They have no idea now really for camera permissions, which is problematic in itself; but the impact has some limits to it (and it was a fait accompli by the time the WG started).
> If we can change their minds, that's different.
Comment 11•10 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #10)
> One correction: we have a) full-screen sharing (most risky, and most
> commonly wanted), b) window sharing (also common, and also commonly the
> window they want to share is from a browser, c) app sharing (effectively the
> same as window, plus exposing popups).
My preference is for b only. The Cisco team working on this, who have a good amount of experience say that app sharing leads to nasty surprises, so they generally don't enable it. And most people can live without desktop sharing. I think that we could continue to provide full desktop sharing for whitelisted sites, but if the bulk of the web only gets window sharing, I think that's fine.
Comment 12•10 years ago
|
||
We don't need HSTS for whitelisted sites. As long as only https pages are whitelisted the same-origin policy and mixed-content-blocker should keep us safe enough.
Assignee | ||
Comment 13•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → ekr
Status: NEW → ASSIGNED
Assignee | ||
Updated•10 years ago
|
Attachment #8487337 -
Flags: review?(sstamm)
Attachment #8487337 -
Flags: review?(martin.thomson)
Comment 14•10 years ago
|
||
Comment on attachment 8487337 [details] [diff] [review]
Require HTTPS for Screen/window sharing
Review of attachment 8487337 [details] [diff] [review]:
-----------------------------------------------------------------
::: dom/media/MediaManager.cpp
@@ +143,5 @@
> + return false;
> + }
> + if (!isHttps) {
> + return false;
> + }
I'd initialize isHttps explicitly and combine the two if statements since they have the same return value, but yeah, looks right.
Attachment #8487337 -
Flags: review?(sstamm) → review+
Updated•10 years ago
|
Attachment #8487337 -
Flags: review?(martin.thomson) → review+
Comment 15•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Reporter | ||
Updated•10 years ago
|
Reporter | ||
Comment 16•10 years ago
|
||
gum_test.html updated to warn on failure, then (timed) auto-reload to https:
Reporter | ||
Comment 17•10 years ago
|
||
Comment on attachment 8487337 [details] [diff] [review]
Require HTTPS for Screen/window sharing
Approval Request Comment
[Feature/regressing bug #]: screensharing
[User impact if declined]: no true privacy for screensharing (MITM/DNS-poisoning attacks can interpose themselves), leading to security attacks
[Describe test coverage new/current, TBPL]: Test page updated and manually tested.
[Risks and why]: almost no risk.
[String/UUID change made/needed]: none
Attachment #8487337 -
Flags: approval-mozilla-beta?
Attachment #8487337 -
Flags: approval-mozilla-aurora?
Comment 18•10 years ago
|
||
Comment on attachment 8487337 [details] [diff] [review]
Require HTTPS for Screen/window sharing
Beta+ and Aurora+
Attachment #8487337 -
Flags: approval-mozilla-beta?
Attachment #8487337 -
Flags: approval-mozilla-beta+
Attachment #8487337 -
Flags: approval-mozilla-aurora?
Attachment #8487337 -
Flags: approval-mozilla-aurora+
Reporter | ||
Comment 19•10 years ago
|
||
Reporter | ||
Comment 20•10 years ago
|
||
Whiteboard: [screensharing-uplift]
You need to log in
before you can comment on or make changes to this bug.
Description
•