1322167 - Vidyo guest links unable to connect to Vidyo desktop client

Status: RESOLVED WORKSFORME

(Core :: DOM: Security, defect, P2)

Description

[Guillermo Huerta [Disabled MoCo account]]

Vidyo guest links are not working in Firefox 51 or later.  They are working with Firefox 50.  I've provided a text link below and will direct the Vidyo engineers to this bug:

https://v.mozilla.com/flex.html?roomdirect.html&key=kiqytHRKk8

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

[Tracking Requested - why for this release]: regression

Comment 2

[Andrew C.]

Hello,
Did anything change in Beta & Dev versions that would prevent communication to local TCP port 63457?  This port is used by VidyoDesktop to communicate with the browser.

Comment 3

[Andrew C.]

Hello,
Adding to my previous note, this is the address VidyoDesktop and the browser uses to communicate with each other:  http://127.0.0.1:63457

Comment 4

[:Gijs (he/him)]

(In reply to Andrew C. from comment #2)
> Hello,
> Did anything change in Beta & Dev versions that would prevent communication
> to local TCP port 63457?  This port is used by VidyoDesktop to communicate
> with the browser.

I don't believe so. You can easily download beta & dev edition versions yourself and check what's going wrong: https://beta.mozilla.org and https://aurora.mozilla.org .

Comment 5

[Guillermo Huerta [Disabled MoCo account]]

We have confirmed that this bug exists in both beta and dev.  We are just getting a time out in the logs.

Comment 6

[:Gijs (he/him)]

(In reply to Guillermo Huerta [:guillermo] from comment #5)
> We have confirmed that this bug exists in both beta and dev.  We are just
> getting a time out in the logs.

It looks to me when trying to look at this that we send a HEAD request to localhost and the vidyo client does not respond to that request. If that's wrong/unexpected (which I think it might be, because it's an <img> request so I dunno why we'd do a CORS request), can someone with decent internet (ie not me, the mozloha wifi is terrible) use mozregression to figure out when this broke?

Comment 7

[Stefan [:StefanG_QA]]

Here is the regression range in aurora:
First good revision: 75ff11d338b2eb7e236362f5da84fc51d3d84cb1
Last bad revision: 55c4ba0e73cdae6e2cfc93f7d195273b15f2f56e
Pushlog: https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=55c4ba0e73cdae6e2cfc93f7d195273b15f2f56e&tochange=75ff11d338b2eb7e236362f5da84fc51d3d84cb1

The last working beta build is 50.0b11 (20161027110534).

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

Looks like the security bug is likely the regressing bug here. NI to the patch author.

Comment 9

[Frederik Braun [:freddy]]

My patch changed how inline JS works with websites that supply a Content-Security-Policy (note the "if (csp)") in the first part of the changeset. Note that v.mozilla.com does *not* use CSP. It can not be the culprit


Looking at the website, I get the following snippet of HTML:
>  <img id="testImage"
>         style="visibility: hidden"
>         src="http://127.0.0.1:63457/dummy?url=https://v.mozilla.com/blank.png?id=388540529770359"
>         onload="javascript: vdInstalled();"
>         onerror="javascript: vdNotInstalled();"/>
>

This image itself is not loaded in Nightly, but loaded in Firefox Release.
The output in the devtools for this particular resource is:

> Loading mixed (insecure) display content “http://127.0.0.1:63457/dummy?url=https://v.mozilla.com/blank.png?id=388540529770359” on a secure pag e[Learn More]

Do we have any recent changes to mixed content loading and localhost?
Are we sure this is the correct regression range?

Comment 10

[Frederik Braun [:freddy]]

Do we have any recent (i.e., now in beta but not yet in release) changes to mixed content loading and localhost?

Comment 11

[Hani Yacoub, Desktop QA]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20161207030204

I tested this issue on Firefox 51.0a1, Firefox 52.0a1 and Firefox 53.0a1, and I managed to reproduce it.

Comment 12

[Kevin Brosnan [Ex-Mozilla]]

If you want an AV Ops bug please file a new one. This bug is for the investigation of what Firefox/Gecko change(s) caused this behavior.

Comment 13

[Kevin Brosnan [Ex-Mozilla]]

[Tracking Requested - why for this release]: regression

Comment 14

[Kevin Brosnan [Ex-Mozilla]]

Yes. The regression range in comment 7 cannot be correct. None of the bugs are fixed on the correct channels compared to the rough regression range we have from prerelease channels.

Comment 15

[Hani Yacoub, Desktop QA]

I only could reproduce it this time on aurora and using Windows 10 32bit, and here is the regression window:


Last good revision: 071d92d893791d2f0cd39ddcec368f3e03d71e8f
First bad revision: aed03debf4f236c5ccbd746f1a8fdb353a2b572b
Pushlog:
https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=071d92d893791d2f0cd39ddcec368f3e03d71e8f&tochange=aed03debf4f236c5ccbd746f1a8fdb353a2b572b

Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=846566

Comment 16

[Julien Cristau [:jcristau]]

tracking this regression for 51+

Comment 17

[Tanvi Vyas[:tanvi]]

(In reply to Frederik Braun [:freddyb] from comment #10)
> Do we have any recent (i.e., now in beta but not yet in release) changes to
> mixed content loading and localhost?

Mixed Content Blocker still considers http://localhost to be mixed content.  I'm not aware of any recent changes to nsMixedContentBlocker, other than the HSTS Priming work that Kate has been doing, which probably shouldn't touch localhost.

The isOriginPotentiallyTrustworthy() method does consider localhost as secure:
http://searchfox.org/mozilla-central/rev/5ee2bd8800b007d6c120d9521d5bf01131885afb/dom/security/nsContentSecurityManager.cpp#608


We do need to unify nsMixedContentBlocker and isOriginPotentiallyTrustworthy at some point.  (example: isOriginPotentiallyTrustwrothy shoudl be taking URI flags into account and nsMixedContentBlocker should be taking localhost into account.)

Comment 18

[Guillermo Huerta [Disabled MoCo account]]

Any thoughts on what team needs to own this bug?

Comment 19

[Johnny Stenback (:jst)]

I spent a chunk of time bisecting this only to come to the conclusion that this is an intermittent problem and my bisection was flawed, so no clear sense of what caused this yet. Jason, can you get someone to dig into why the image load fails in this case, apparently intermittently. This is busted on beta, so not a whole ton of time left to dig into this regression.

Comment 20

[Johnny Stenback (:jst)]

Need info on jduell to make sure he sees this one.

Comment 21

[Kevin Brosnan [Ex-Mozilla]]

Please stop moving this bug. It breaks a ton of the tracking flags we use in Firefox. As I said above please make a clone of this bug if you want something for AV OPs to own.

Comment 22

[Kevin Brosnan [Ex-Mozilla]]

[Tracking Requested - why for this release]: Flags were removed by moving the bug please reset them to +

Comment 23

[Julien Cristau [:jcristau]]

restoring tracking flags

Comment 24

[Jason Duell]

Selena--I'm happy to put someone on this as needed, but so far we're smelling like this is a mixed-content issue (based on comment 9) which is not our wheelhouse.  Feel free to throw this back at me if I'm wrong.

Comment 25

[Selena Deckelmann :selenamarie :selena]

Christoph -- could you look into this and determine whether this is a mixed-content issue? See comment 9 and comment 10.

Comment 26

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Adding a need info for myself so I remember to find someone to look at this.

Comment 27

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Kate is looking into this as it is possibly a HSTS issue.

Comment 28

[Kate McKinley [:kmckinley, :Kate]]

This looks like it is related to HSTS priming request timing out, which should be mitigated by Bug 1313595. Setting security.mixed_content.send_hsts_priming to false causes the Vidyo popup to happen nearly instantaneously.

Additionally, HSTS priming should not be occurring for numeric IP addresses as HSTS doesn't affect IP addresses.

Comment 29

[Guillermo Huerta [Disabled MoCo account]]

This seems to have been resolved in 51 with the closure of 1313595.  When would that hit 52 and 53?

Comment 30

[Andrew C.]

Hello (In reply to Guillermo Huerta [Disabled MoCo account] from comment #29)
> This seems to have been resolved in 51 with the closure of 1313595.  When
> would that hit 52 and 53?

Hello Guillermo, can you try on 51.0.1(32-bit) and share your results.  I'm seeing the same issue on this release.

Comment 31

[Kevin Brosnan [Ex-Mozilla]]

Guillermo has switched jobs. I believe setting security.mixed_content.send_hsts_priming to false which Firefox 51.0.2 will provide will allow this to function.

Comment 32

[Andrew C.]

(In reply to Kevin Brosnan [:kbrosnan] from comment #31)
> Guillermo has switched jobs. I believe setting
> security.mixed_content.send_hsts_priming to false which Firefox 51.0.2 will
> provide will allow this to function.

Hello Kevin, 
We are seeing this behavior on 51.0.1 as well.  Are there any upcoming changes that will not require changing security.mixed_content.send_hsts_priming to false?

Comment 33

[Andrew C.]

(In reply to Kevin Brosnan [:kbrosnan] from comment #31)
> Guillermo has switched jobs. I believe setting
> security.mixed_content.send_hsts_priming to false which Firefox 51.0.2 will
> provide will allow this to function.

Hello. I tested on 52.0b4(64-bit) and our links are working.  Will Mozilla be implementing the same changes in HSTS on the next release?

Test link:  https://uvd.vidyocloud.com/flex.html?roomdirect.html&key=CE4Oj4I48p
about:config = security.mixed_content.send_hsts_priming = TRUE

Comment 35

[Loic]

security.mixed_content.send_hsts_priming has been switched to false in Release/Beta after bug 1335224 pushed as add-on update.

If the user has selected "Check for updates, but let me choose whether to install them" or "Never check for updates" in the options, the patch from bug 1335224 can't be pushed. He needs to select "Automatically install updates" to apply the update.

Comment 36

[Alexander]

(In reply to Loic from comment #35)
> security.mixed_content.send_hsts_priming has been switched to false in
> Release/Beta after bug 1335224 pushed as add-on update.
> 
> If the user has selected "Check for updates, but let me choose whether to
> install them" or "Never check for updates" in the options, the patch from
> bug 1335224 can't be pushed. He needs to select "Automatically install
> updates" to apply the update.


(...also following the thread of bug 1338784...)

Here are the correlations on my system:

FF
version
50.1.0  Vidyo:yes    parameter security.mixed_content.send_hsts_priming : NOT EXISTING
51.0.1  Vidyo:no     security.mixed_content.send_hsts_priming = true
                            -- independently of "Check for updates" or "Automatically install updates""
52.0b7  Vidyo:yes    security.mixed_content.send_hsts_priming = false
                              "Check for updates" selected

Comment 37

[Andrew C.]

(In reply to Loic from comment #35)
> security.mixed_content.send_hsts_priming has been switched to false in
> Release/Beta after bug 1335224 pushed as add-on update.
> 
> If the user has selected "Check for updates, but let me choose whether to
> install them" or "Never check for updates" in the options, the patch from
> bug 1335224 can't be pushed. He needs to select "Automatically install
> updates" to apply the update.

I've tested this scenario, selected "Automatically install updates" but the following config remains the same:

security.mixed_content.send_hsts_priming = true

Doesn't seem like any add-on is beingg pushed.  I've reinstalled FF 51.0.1 and selected "Automatically install updates" but to no avail.  The About menu tells me that "Firefox is up to date"

Comment 38

[Loic]

(In reply to Andrew C. from comment #37)
> (In reply to Loic from comment #35)
> > security.mixed_content.send_hsts_priming has been switched to false in
> > Release/Beta after bug 1335224 pushed as add-on update.
> > 
> > If the user has selected "Check for updates, but let me choose whether to
> > install them" or "Never check for updates" in the options, the patch from
> > bug 1335224 can't be pushed. He needs to select "Automatically install
> > updates" to apply the update.
> 
> I've tested this scenario, selected "Automatically install updates" but the
> following config remains the same:
> 
> security.mixed_content.send_hsts_priming = true
> 
> Doesn't seem like any add-on is beingg pushed.  I've reinstalled FF 51.0.1
> and selected "Automatically install updates" but to no avail.  The About
> menu tells me that "Firefox is up to date"

The update via the add-on system is not immediate, probaly it'll happen after the next restart or in one day. After the update applied, you should find the hsts-priming add-on patch (called "Send HSTS Priming Requests") in the extension table in about:support.

Comment 39

[Andrew C.]

(In reply to Loic from comment #38)
> (In reply to Andrew C. from comment #37)
> > (In reply to Loic from comment #35)
> > > security.mixed_content.send_hsts_priming has been switched to false in
> > > Release/Beta after bug 1335224 pushed as add-on update.
> > > 
> > > If the user has selected "Check for updates, but let me choose whether to
> > > install them" or "Never check for updates" in the options, the patch from
> > > bug 1335224 can't be pushed. He needs to select "Automatically install
> > > updates" to apply the update.
> > 
> > I've tested this scenario, selected "Automatically install updates" but the
> > following config remains the same:
> > 
> > security.mixed_content.send_hsts_priming = true
> > 
> > Doesn't seem like any add-on is beingg pushed.  I've reinstalled FF 51.0.1
> > and selected "Automatically install updates" but to no avail.  The About
> > menu tells me that "Firefox is up to date"
> 
> The update via the add-on system is not immediate, probaly it'll happen
> after the next restart or in one day. After the update applied, you should
> find the hsts-priming add-on patch (called "Send HSTS Priming Requests") in
> the extension table in about:support.

Hello Loic,
I appreciate the response.  I have two questions:

#1
I've found that a reboot is required in order for the "Send HSTS Priming Requests" to show in the "Extensions" section for about:support.  I have a Windows machine that's been on for 1 week and is currently on FF 51.0.1

#2
Will this add-on be required for the next release of FF? Or will the next release already have "security.mixed_content.send_hsts_priming = false"?

Comment 40

[Loic]

(In reply to Andrew C. from comment #39)

> Will this add-on be required for the next release of FF? Or will the next
> release already have "security.mixed_content.send_hsts_priming = false"?

No, it will be false by default, this add-on is just a quick bugfix after the release of 51.

Comment 41

[Julien Cristau [:jcristau]]

Updating status for 51 (hsts priming disabled by system addon) and 52 (disabled by default).

Comment 42

[Daniel Veditz [:dveditz]]

(In reply to Andrew C. from comment #33)
> Will Mozilla be implementing the same changes in HSTS on the next release?

We'll definitely have this enabled in development builds, not sure when it will hit general release since it's a new feature in the process of being standardized. Chrome is also interested in the concept though I don't think they've committed to implementing it yet.

Comment 43

[Liz Henry (:lizzard) (relman/hg->git project)]

Kate, what is the status here for 53 on beta and then for release?

Comment 44

[Kate McKinley [:kmckinley, :Kate]]

HSTS priming is disabled on Beta and Release, and no current plans to let it ride the trains.

Comment 45

[Kate McKinley [:kmckinley, :Kate]]

Marking this as resolved since HSTS priming was removed from the tree in Bug 1424917