u609459 Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171226083017

Steps to reproduce:

Monitored the network traffic generated by the OpenH264 Video Codec add-on installed in a Firefox Developer Edition installation on MacOS (57.0.3 64-bit).
This behavior may exist for plug in installation and plug in update mechanisms.


Actual results:

The browser made an outbound HTTP connection to http://ciscobinary.openh264.org/openh264-macosx64-0410d336bb748149a4f560eb6108090f078254b1.zip




Expected results:

The same zip archive is available over a HTTPS endpoint at https://ciscobinary.openh264.org/openh264-macosx64-0410d336bb748149a4f560eb6108090f078254b1.zip

	Andrew Swan [:aswan]
	Comment 1 • 7 years ago

not sure if this is the right component but its closer

	Paul Adenot (:padenot)
	Comment 2 • 7 years ago

Chris, is that intentional? I think we check a signature still don't we?

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 3 • 7 years ago

I assume we're talking about the plugin install process using HTTP to download the plugin, rather than the  plugin making a network request itself, as it shouldn't be able to do that as its sandboxed.

We should be using HTTPS, not HTTP, for the download of OpenH264. We still check the signature, and we retrieve the signature over HTTPS from a Mozilla controlled server, so we're probably fine, but it's still good practice to use HTTPS here.

Nils: our OpenH264 download URLs should be HTTPS, not HTTP... Any reason why they're not?

	Nils Ohlmeier [:drno]
	Comment 4 • 7 years ago

While I agree that it would be good practice to download the plugin via HTTPS we currently can't do it, because the URL points to Akamai without a valid certificate for the domain. So that needs to get fixed first before we could start downloading via HTTPS.

	Nils Ohlmeier [:drno]
	Comment 5 • 7 years ago

Firefox knows a SHA-256 hash of the binary from when the OpenH264 plugin got build by us, which gets verified after the download. Plus the plugin contains a signature from Mozilla which gets verified before the plugin gets installed. That should be sufficient to rule out that Firefox will install something else then the expected original plugin from Openh264.org and Mozilla.

Obviously anyone on the route between Firefox and Akamai can currently see that it's downloading the OpenH264 plugin. But I fail to see how that could be sensitive information as every Firefox browser in world downloads it after installation. Plus a HTTPS connection to ciscobinary.openh264.org would still tell everyone on that route that the OpenH264 plugin currently gets downloaded. So even encrypting the transport will not hide that information.

Ashwin what is the threat model you are concern about and how does a switch to HTTPS solve that?

	Andreas Pehrson [:pehrsons] (back on Aug 5)
	Comment 6 • 7 years ago

Sounds like something we want but don't necessarily need, so P3.

	u609459 Reporter
	Comment 7 • 7 years ago

Hi all,

Apologies for the delayed response. The concern was around a potential MiTM attack against the updater or the update file thereby bringing into question the integrity of the delivered update as opposed to the confidentiality. The attack itself is described in CAPEC-186 (https://capec.mitre.org/data/definitions/186.html). 

The risk shifts to the hashes and the validation mechanism used to validate the file once retrieved. If the hashes are baked into the browser, would it not be required to be updated with every release? If so, are these hashes updated over a secure channel?

A switch to HTTPS would solve the integrity issue and I am assuming that the browser could technically validate the openh264.org endpoint's certificate as it would any other HTTPS connection.

If I am missing the obvious, I apologise in advance.

	Andreas Pehrson [:pehrsons] (back on Aug 5)
	Comment 8 • 7 years ago

Nils, could you follow up on how we get these hashes?

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 9 • 7 years ago

We produce the hashes ourselves, and we download the hash of the ZIP along with the download URL from a server controlled by Mozilla over HTTPS, and the SSL certificate for the update server is pinned. So we can be confident that the download URL and the hash of the ZIP are downloaded over a secure channel and can't be MITMed. In fact, we've had bugs filed where the download (of Widevine, the other plugin we use) fails for users that *have* been MITM'd by various spyware, "security" and "coupon" products.

So I'm confident we can be sure the binary is the one we think it is when we install it, irrespective of whether the GMP is downloaded over HTTPS or not.

	Nils Ohlmeier [:drno]
	Comment 10 • 7 years ago

The other "problem" is that as you can see from the download URL you provided in the initial report the host is actually not owned or maintained by Mozilla. It might make more sense to open an issue on the OpenH264 GitHub repo https://github.com/cisco/openh264 to ask Cisco to add a valid certificate to the already enabled HTTPS CDN.