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

Status: NEW

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

Description

[Zack Weinberg (:zwol)]

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.

Comment 1

[Patrick McManus [:mcmanus]]

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.

Comment 2

[Daniel Veditz [:dveditz]]

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

Comment 3

[Patrick McManus [:mcmanus]]

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.

Comment 4

[Benjamin Smedberg]

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.

Comment 5

[Ethan Hugg [:ehugg]]

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?

Comment 6

[Maire Reavy [:mreavy]]

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

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Maire Reavy [:mreavy]]

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.

Comment 9

[Ethan Hugg [:ehugg]]

We need input from Cullen on this.  I don't think this is possible with our current CDN setup.

Comment 10

[Cullen Jennings]

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.

Comment 11

[Patrick McManus [:mcmanus]]

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.

Comment 12

[Richard Z.]

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.

Comment 13

[Richard Z.]

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

Comment 14

[Richard Z.]

(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

Comment 15

[Jesse Ruderman]

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

Comment 16

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 17

[Müller Zsolt]

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