net: don't allow SSLv3 fallback for Google properties.

net: don't allow SSLv3 fallback for Google properties.

This change reverts r199185 ("Disable SSL3 fallback restriction on Google
properties") and pokes a whole in the HSTS tables to account for
crbug.com/237055.

BUG=237055
R=palmer@chromium.org, rsleevi@chromium.org, wtc@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=221192

[Ryan Sleevi, 2013-09-03 18:04:09]

I'm not thrilled with having to include the hostname in the public list, but
this CL effectively does that, so in for a penny.

If we find ourselves needing to cut more holes, then I suggest we try to wire
something up to enterprise policy. This is doubly so if we try to move towards a
'default on' on disabling the fallback mechanism, and an enterprise-configurable
blacklist for cutting holes if needed.

Or do you see us not being able to get to a 'default on' position?

Either way, we can follow-up on these comments on the bug, this CL itself LGTM.

[wtc, 2013-09-03 18:17:16]

Patch set 1 LGTM.

https://codereview.chromium.org/23523016/diff/1/net/http/transport_security_s...
File net/http/transport_security_state_static.json (right):

https://codereview.chromium.org/23523016/diff/1/net/http/transport_security_s...
net/http/transport_security_state_static.json:204: { "name":
"oraprodsso.corp.google.com", "include_subdomains": true, "mode": "force-https"
},

It seems that  include_subdomains should be false. Does this hostname have
subdomains, or is this defensive programming?

Why does adding a mode=force-https entry poke a hole for this hostname?

(Note: the CL description has a typo: "pokes a whole".)

[palmer, 2013-09-03 18:20:45]

https://codereview.chromium.org/23523016/diff/1/net/http/transport_security_s...
File net/http/transport_security_state_static.json (right):

https://codereview.chromium.org/23523016/diff/1/net/http/transport_security_s...
net/http/transport_security_state_static.json:204: { "name":
"oraprodsso.corp.google.com", "include_subdomains": true, "mode": "force-https"
},
> It seems that  include_subdomains should be false. Does this hostname have
> subdomains, or is this defensive programming?

agl probably intends to be defensive, and it makes sense to me.

> Why does adding a mode=force-https entry poke a hole for this hostname?

Most specific hostname match matches first, so this policy overrides more
general policies.

[palmer, 2013-09-03 18:21:58]

LGTM BTW FWIW FTW

[agl, 2013-09-03 20:04:24]

On 2013/09/03 18:17:16, wtc wrote:
> It seems that  include_subdomains should be false. Does this hostname have
> subdomains, or is this defensive programming?

I'll always include subdomains unless there's a reason not to.

> Why does adding a mode=force-https entry poke a hole for this hostname?

mode=force-https is there because entries need to have either a mode, or have
pins. In this case, the important part is that it not have Google pins, since
that's the indicator that the fallback code is keying off. The force-https does
make it HSTS where it wasn't before, but the host is already only used with
HTTPS.

[commit-bot: I haz the power, 2013-09-03 20:04:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/agl@chromium.org/23523016/1

[commit-bot: I haz the power, 2013-09-03 20:19:50]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[agl, 2013-09-04 16:10:34]

Committed patchset #1 manually as r221192 (presubmit successful).