Open Bug 1102531 Opened 10 years ago Updated 1 year ago

On-demand download of Cisco H.264 plugin should occur over HTTPS

Categories

(Core :: Audio/Video: GMP, defect, P3)

Product:
Core
Component:
Audio/Video: GMP
Type:
defect

Tracking

()

People

(Reporter: zwol, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: sec-want) 

From @j4cob on Twitter [ https://twitter.com/j4cob/status/535562724546052096 ]:
> Hey Firefox, why are you downloading
> http://ciscobinary.openh264.org/openh264-linux32-v1.1-Firefox33.zip 
> over insecure HTTP on startup?

Perhaps there is a signature or at least a secure hash of the expected file baked into Firefox proper - I haven't checked - but it'd be better to do the download over HTTPS *as well as* checking such a hash, for three reasons:

* It gives people who worry about these things more warm fuzzies.

* If there is some exploitable code path in between the download and
  the signature check (perhaps the signature is over the binary inside
  the zipfile, and the zip exploder is exploitable?) HTTPS would block
  anyone from exploiting it.

* It makes it slightly harder for someone eavesdropping to know
  what is going on.  In this case I imagine this is the only thing
  we ever pull from ciscobinary.openh264.org, so it doesn't help much,
  but it would facilitate a future move to a more aggressively
  traffic-analysis-proof download method - say, serving the file ourselves
  off the Firefox update server.
Keywords: sec-want
We should be doing all https:// if we expect other people to. This should be fixed... it has a better confidentiality story too - especially if combined with proxies and overlays that obscure some of the IP layer identification at various points.
I agree using https:// would be a helpful step in reassuring people, but the openH264 download is modeled on our own updates from the CDN and should be as secure.

1) first we check for updates from https://aus4.mozilla.org/ -- example:
https://aus4.mozilla.org/update/3/GMP/36.0a1/20141120030202/WINNT_x86-msvc/en-US/nightly/Windows_NT%206.1.1.0%20%28x64%29/default/default/update.xml

We are not currently using "real" cert pinning on aus4 (unlike versioncheck.addons.mozilla.org), but we do have some internal cert sanity checks for MITM (that has caught some, e.g. bug 1087674 comment 32. Then again our "real" cert pinning defaults to allowing MITM if it chains to a user-installed root so the Avast A-V MITM would have worked. Feature or bug? There's a pref for that)

2) We then download the file from the given URL. Cisco for OpenH264, our CDN for Firefox updates.

3) after the download we validate the hash and the filesize match before doing anything
at the risk of repeating myself - my take on this is that https provides user benefit in this case. It's not about mozilla's software integrity which I think we're all ok with.

https creates some, imperfect, transport confidentiality and privacy for our users and we want that to be ubiquitous.. so it seems wise to lead with own associated content.
HTTPS was not a deployment requirement, but we can/should ask them to make it available via HTTPS instead of HTTP. Maire, is that something you can coordinate with Cisco? Once it's available, making the change on our side is pretty trivial.
Flags: needinfo?(mreavy)
https://ciscobinary.openh264.org/openh264-linux32-v1.1-Firefox33.zip

It is already available via HTTPS, but the cert will say Akamai.  Will that work for you?
(In reply to Ethan Hugg [:ehugg] from comment #5)
> https://ciscobinary.openh264.org/openh264-linux32-v1.1-Firefox33.zip
> 
> It is already available via HTTPS, but the cert will say Akamai.  Will that work for you?

Benjamin -- Is there a way for us to work around this, or does this need to be on a Cisco cert?
Flags: needinfo?(mreavy) → needinfo?(benjamin)
We would have to hard-code the ciscobinary.openh264.org -> akamai certificate mapping in the client, which sounds fragile and is not a good idea. I think we want normal SSL.
Flags: needinfo?(benjamin)
Ethan and Shell -- Let's plan to talk offline about how easily Cisco could make this change and what the timing would look like.  Thanks.
Flags: needinfo?(sescalante)
Flags: needinfo?(ethanhugg)
We need input from Cullen on this.  I don't think this is possible with our current CDN setup.
Flags: needinfo?(ethanhugg) → needinfo?(fluffy)
So note this breaks caching, stops network virus checkers, makes install slower and uses more bandwidth. All the reasons people argue that we should be doing a MITM of HTTPS. What security goal are you trying to achieve? (and note I am guy with a "TLS Everywhere" tattoo but convince me why we are doing TLS here helps). 

Actually just convince EKR and have him summarize it for me :-) We can probably figure out how to do this if it is the right thing but it's not obvious to me that it is. It would not be possible with the current set up but I imagine there are ways we could find to do it.
Flags: needinfo?(fluffy)
I come at this from https://www.mozilla.org/en-US/about/manifesto/ - #4 and privacy. That includes transport confidentiality whenever we can do it even though we all know https can leak information.

I'm not sure whether or not I would call that a security goal. Its related.

Deprecating plaintext is, on balance, overall in everyone's interest. That can't be done when even new internal (ish) services are being deployed using it.
Definitely want the added privacy. 

Downloading over plain http makes it trivially easy for anyone on an open  WIFI to get lots of details about my device.

The easiest and most versatile OS/Browser fingerprinting method I did come across in recent years. No user action or confirmation involved, no javascript, 100%  passive.
(In reply to Daniel Veditz [:dveditz] from comment #2)
> I agree using https:// would be a helpful step in reassuring people, but the
> openH264 download is modeled on our own updates from the CDN and should be
> as secure.
> 
> 1) first we check for updates from https://aus4.mozilla.org/ -- example:
> https://aus4.mozilla.org/update/3/GMP/36.0a1/20141120030202/WINNT_x86-msvc/
> en-US/nightly/Windows_NT%206.1.1.0%20%28x64%29/default/default/update.xml
> 
> We are not currently using "real" cert pinning on aus4 (unlike
> versioncheck.addons.mozilla.org), but we do have some internal cert sanity
> checks for MITM (that has caught some, e.g. bug 1087674 comment 32. Then
> again our "real" cert pinning defaults to allowing MITM if it chains to a
> user-installed root so the Avast A-V MITM would have worked. Feature or bug?
> There's a pref for that)

now real cert pinning, no PGP verified signature?

Did anybody give a thought to PGP verified signatures or jarsigner?

Relying on plain SSL to aus4.mozilla.org as the only only mean of integrity is asking for disaster.
(In reply to Ethan Hugg [:ehugg] from comment #5)
> https://ciscobinary.openh264.org/openh264-linux32-v1.1-Firefox33.zip
> 
> It is already available via HTTPS, but the cert will say Akamai.  Will that
> work for you?

it could be good enough if done like this:

aus4.mozilla.org provides
 - cisco download URL (https)
 - PGP encoded fingerprint of cisco server certificate
 - PGP encoded checksum of binary
Flags: needinfo?(sescalante)
Since the connection happens over HTTP, I hope it uses a separate cookie jar from browsing, so a MITMer can't grab all my HTTP cookies in a series of redirects
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Component: Audio/Video: MediaStreamGraph → Audio/Video: GMP
Rank: 25
Priority: -- → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
(In reply to Jesse Ruderman from comment #15)
> Since the connection happens over HTTP, I hope it uses a separate cookie jar
> from browsing, so a MITMer can't grab all my HTTP cookies in a series of
> redirects

They can only grab the ones where:
- the MITMer successfully guesses the domain from where you've a cookie stored
- the cookie does not have the "secure" flag set

Nowadays hopefully all services "that matter" use the "secure" flag for their cookies.

Plus I hope that Firefox has some sane limit on number of redirections in a single HTTP request. :o
It doesn't sound fun if an MITMer can issue redirects indefinitely.

This is still a problem, and I ran into an issue with this recently.
I spent a few days trying to figure out why I couldn't play videos in Firefox.

If HTTPS-Only mode is enabled, the H.264 plugin will fail to install due to this invalid certificate.
I ended up disabling HTTPS-Only mode after figuring that out, and the plugin was installed successfully.

https://support.mozilla.org/en-US/questions/1387711

Using Firefox version 104.0.1 (64-bit)

Severity: normal → S3

(In reply to CorruptComputer from comment #18)

This is still a problem, and I ran into an issue with this recently.
I spent a few days trying to figure out why I couldn't play videos in Firefox.

If HTTPS-Only mode is enabled, the H.264 plugin will fail to install due to this invalid certificate.
I ended up disabling HTTPS-Only mode after figuring that out, and the plugin was installed successfully.

https://support.mozilla.org/en-US/questions/1387711

Using Firefox version 104.0.1 (64-bit)

Any better with 109.0.1?

Looks like that version isn't available in the Fedora repos yet, but I just tried it with 109.0 and its still just forever sitting at "OpenH264 Video Codec provided by Cisco Systems, Inc. will be installed shortly." when HTTPS-Only mode is enabled. If I disable HTTPS-Only it installs immediately after restarting the browser.

Tested again today with 109.0.1 and the same issue is happening with that version as well.

We are supposed to allow GMP plugin updates to skip HTTPS:
https://searchfox.org/mozilla-central/rev/c244b16815d1fc827d141472b9faac5610f250e7/toolkit/modules/GMPInstallManager.sys.mjs#732
https://searchfox.org/mozilla-central/rev/8c971ce95edd7bf0c266dc28abb780ec13cd05e8/dom/security/nsHTTPSOnlyUtils.cpp#156

I wonder if this is able to explain why some users are stuck on older Widevine plugins.....(Edit: Widevine uses HTTPS, so no.)

I verified in a local build that after turning on HTTPS only mode, closing Firefox, deleting the GMP plugin folders, restarting, going to the Shaka player demo, both plugins got reinstalled.

Some of the distros replace Mozilla's OpenH264 plugin because it is too old. It is possible there is some interaction between HTTPS mode and the distro patches? We are in the process of updating our version, see bug 1619988.

CorruptComputer, I am happy to investigate further if you are able to provide a log for me. Collecting it with "nsHttp:5,GMP:5" turned on should be sufficient -- given this will include URLs from your browsing in general, it would be best if you trigger the plugins to attempt to download after startup and do nothing else.

Flags: needinfo?(CorruptComputer)

(In reply to CorruptComputer from comment #20)

Fedora

Fedora's Firefox is started with MOZ_GMP_PATH environment variable and sets media.gmp-gmpopenh264.autoupdate:false media.gmp-gmpopenh264.version:"system-installed" by default.
I can reproduce this. My STR are in bug 1663844 comment 18:
The video is played using GMP-Openh264 loaded via MOZ_GMP_PATH envionment variable.
I open a second tab: about:addons > Plugins: The yellow "[...] will be installed shortly" info is displayed - while the video is already playing.
It also doesn't display the version of GMP-OpenH264 loaded via MOZ_GMP_PATH.

Flags: needinfo?(CorruptComputer)
You need to log in before you can comment on or make changes to this bug.