Allow fallback from https to http for component update checks.

Allow fallback from https to http for component update checks.

Component updater relies on its custom message signing protocol to
guarantee the integrity of update checks.

As a failover mechanism and to improve the update success rates,
fallback to HTTP is allowed. This is similar to
what Google Update (Omaha) has been doing.

BUG=590070
Committed: https://crrev.com/fccbf2db6bcb97e556e46f8ca15437de38657cf5
Cr-Commit-Position: refs/heads/master@{#384993}

[Sorin Jianu, 2016-02-27 00:44:38]

Description was changed from

==========
Allow fallback from https to http for component update checks.

Component updater relies on its custom message signing protocol to
guarantee the integrity of update checks.

As a failover mechanism and to improve the update success rates,
fallback to HTTP is allowed. This is similar to
what Google Update (Omaha) has been doing.

BUG=590070
==========

to

==========
Allow fallback from https to http for component update checks.

Component updater relies on its custom message signing protocol to
guarantee the integrity of update checks.

As a failover mechanism and to improve the update success rates,
fallback to HTTP is allowed. This is similar to
what Google Update (Omaha) has been doing.

BUG=590070
==========

[Sorin Jianu, 2016-02-27 00:44:38]

sorin@chromium.org changed reviewers:
+ asargent@chromium.org, rohitrao@chromium.org, waffles@chromium.org

[Sorin Jianu, 2016-02-27 00:46:32]

Please, I need owners approval for the files under:
chrome\browser\extensions\updater\chrome_update_client_config.cc
ios\chrome\browser\component_updater\ios_component_updater_configurator.cc

The change for the extension updater is mechanical.

The change for iOS would result in sending component update traffic over HTTP is
some cases. where HTTPS does not work.

[Sorin Jianu, 2016-02-27 00:47:41]

The CQ bit was checked by sorin@chromium.org to run a CQ dry run

[rohitrao (ping after 24h), 2016-02-27 00:51:42]

ios/ code changes LGTM assuming security and other stakeholders have signed off
on this change

[commit-bot: I haz the power, 2016-02-27 00:53:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1740333002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1740333002/1

[waffles, 2016-02-27 01:43:56]

lgtm

[asargent_no_longer_on_chrome, 2016-02-29 18:26:09]

Code change in chrome/browser/extensions lgtm

However, I'd strongly advise you to get security sign off before rolling this
out if you haven't already. In the past, the fact that most extension updates
went over https was a helpful second line of defense-in-depth against problems
with signing keys being accidentally disclosed. I understand that chrome binary
components are different and the keys are never in the hands of 3rd parties, but
I think the general principle still stands and it's not like we're immune from
making mistakes. 

Having a fallback to plain http means it's fairly easy for attackers to force
this and remove the line of defense, so I think the benefits need to be
carefully weighed against the (imho, large) downsides.

https://codereview.chromium.org/1740333002/diff/40001/chrome/browser/extensio...
File chrome/browser/extensions/updater/chrome_update_client_config.cc (right):

https://codereview.chromium.org/1740333002/diff/40001/chrome/browser/extensio...
chrome/browser/extensions/updater/chrome_update_client_config.cc:21: true) {}
please include a comment hinting at the meaning of this boolean, so that readers
don't have to go look it up, e.g.

true /* require_encryption */)

[Sorin Jianu, 2016-04-03 22:51:52]

The CQ bit was checked by sorin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-03 22:52:01]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1740333002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1740333002/60001

[commit-bot: I haz the power, 2016-04-03 22:56:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-03 22:56:13]

Dry run: Try jobs failed on following builders:
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)

[Sorin Jianu, 2016-04-04 16:56:34]

The CQ bit was checked by sorin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-04 16:57:00]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1740333002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1740333002/80001

[Sorin Jianu, 2016-04-04 17:15:18]

sorin@chromium.org changed reviewers:
+ agl@chromium.org

[Sorin Jianu, 2016-04-04 17:20:30]

Adam, I need the owners' approval for the paths including crl_set.

This is a large change, but the summary of it is that there are no privacy
concerns regarding the CRL set component in the context of the component
updates. The network traffic associated with updates to CRL set does not require
confidentiality, therefore, the component updater can use both HTTPS and HTTP to
talk to Google.

The data integrity for updates is guaranteed by other mechanisms, already in
place.

[commit-bot: I haz the power, 2016-04-04 17:43:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-04 17:43:04]

Dry run: This issue passed the CQ dry run.

[waffles, 2016-04-04 17:44:44]

lgtm

https://codereview.chromium.org/1740333002/diff/80001/components/update_clien...
File components/update_client/request_sender.h (right):

https://codereview.chromium.org/1740333002/diff/80001/components/update_clien...
components/update_client/request_sender.h:41: // when the response was received
from a cryptografically secure URL. The
cryptografically → cryptographically

https://codereview.chromium.org/1740333002/diff/80001/components/update_clien...
File components/update_client/utils.cc (right):

https://codereview.chromium.org/1740333002/diff/80001/components/update_clien...
components/update_client/utils.cc:242: void
RemoveUnsecureUrls(std::vector<GURL>* urls) {
It might be worth calling this "RemoveEncryptedUrls" or
"RemoveConfidentialUrls", since all our communications are "Secure" via CUP.

(If you do this, same idea elsewhere for local variable names, etc.)

[Sorin Jianu, 2016-04-04 18:01:19]

The CQ bit was checked by sorin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-04 18:01:39]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1740333002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1740333002/100001

[Sorin Jianu, 2016-04-04 18:01:40]

Thank you waffles@

https://codereview.chromium.org/1740333002/diff/80001/components/update_clien...
File components/update_client/request_sender.h (right):

https://codereview.chromium.org/1740333002/diff/80001/components/update_clien...
components/update_client/request_sender.h:41: // when the response was received
from a cryptografically secure URL. The
On 2016/04/04 17:44:44, waffles wrote:
> cryptografically → cryptographically

Done.

https://codereview.chromium.org/1740333002/diff/80001/components/update_clien...
File components/update_client/utils.cc (right):

https://codereview.chromium.org/1740333002/diff/80001/components/update_clien...
components/update_client/utils.cc:242: void
RemoveUnsecureUrls(std::vector<GURL>* urls) {
On 2016/04/04 17:44:44, waffles wrote:
> It might be worth calling this "RemoveEncryptedUrls" or
> "RemoveConfidentialUrls", since all our communications are "Secure" via CUP.
> 
> (If you do this, same idea elsewhere for local variable names, etc.)

Acknowledged.

[commit-bot: I haz the power, 2016-04-04 19:57:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-04 19:57:54]

Dry run: This issue passed the CQ dry run.

[Sorin Jianu, 2016-04-04 20:08:15]

sorin@chromium.org changed reviewers:
+ rsleevi@chromium.org

[Sorin Jianu, 2016-04-04 20:09:43]

Ryan, could you please help with the owners' approval for crl set paths?

It appears that agl@ is OOO for the rest of the week.

Thank you!

[Ryan Sleevi, 2016-04-04 20:25:11]

CRLSet change LGTM

[Sorin Jianu, 2016-04-04 20:27:19]

The CQ bit was checked by sorin@chromium.org

[Sorin Jianu, 2016-04-04 20:27:20]

The patchset sent to the CQ was uploaded after l-g-t-m from
rohitrao@chromium.org, asargent@chromium.org, waffles@chromium.org
Link to the patchset: https://codereview.chromium.org/1740333002/#ps100001
(title: " ")

[commit-bot: I haz the power, 2016-04-04 20:27:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1740333002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1740333002/100001

[commit-bot: I haz the power, 2016-04-04 20:34:42]

Description was changed from

==========
Allow fallback from https to http for component update checks.

Component updater relies on its custom message signing protocol to
guarantee the integrity of update checks.

As a failover mechanism and to improve the update success rates,
fallback to HTTP is allowed. This is similar to
what Google Update (Omaha) has been doing.

BUG=590070
==========

to

==========
Allow fallback from https to http for component update checks.

Component updater relies on its custom message signing protocol to
guarantee the integrity of update checks.

As a failover mechanism and to improve the update success rates,
fallback to HTTP is allowed. This is similar to
what Google Update (Omaha) has been doing.

BUG=590070
==========

[commit-bot: I haz the power, 2016-04-04 20:34:43]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-04-04 20:36:09]

Description was changed from

==========
Allow fallback from https to http for component update checks.

Component updater relies on its custom message signing protocol to
guarantee the integrity of update checks.

As a failover mechanism and to improve the update success rates,
fallback to HTTP is allowed. This is similar to
what Google Update (Omaha) has been doing.

BUG=590070
==========

to

==========
Allow fallback from https to http for component update checks.

Component updater relies on its custom message signing protocol to
guarantee the integrity of update checks.

As a failover mechanism and to improve the update success rates,
fallback to HTTP is allowed. This is similar to
what Google Update (Omaha) has been doing.

BUG=590070

Committed: https://crrev.com/fccbf2db6bcb97e556e46f8ca15437de38657cf5
Cr-Commit-Position: refs/heads/master@{#384993}
==========

[commit-bot: I haz the power, 2016-04-04 20:36:11]

Patchset 6 (id:??) landed as
https://crrev.com/fccbf2db6bcb97e556e46f8ca15437de38657cf5
Cr-Commit-Position: refs/heads/master@{#384993}