1063730 - Screensharing (windows, apps) should only be allowed on https: origin sites

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

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

[Ethan Hugg [:ehugg]]

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.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

(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

[Martin Thomson [:mt:]]

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

[Ethan Hugg [:ehugg]]

(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

[Martin Thomson [:mt:]]

(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

[Gian-Carlo Pascutto [:gcp]]

(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

[Martin Thomson [:mt:]]

(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

[Gian-Carlo Pascutto [:gcp]]

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

[Martin Thomson [:mt:]]

(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.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

(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

[Martin Thomson [:mt:]]

(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

[Daniel Veditz [:dveditz]]

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.

Comment 13

[Eric Rescorla (:ekr)]

Attachment: Require HTTPS for Screen/window sharing

Comment 14

[Sid Stamm [:geekboy or :sstamm]]

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.

Comment 15

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/mozilla-central/rev/b0f9e80e8255

Comment 16

[Randell Jesup [:jesup] (needinfo me)]

gum_test.html updated to warn on failure, then (timed) auto-reload to https:

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8487337 [details] [diff] [review]
Require HTTPS for Screen/window sharing

Beta+ and Aurora+

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/0807d8ab3e5a

Comment 20

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/releases/mozilla-beta/rev/a706b85f6d4d