Disable commonName matching for certificates

Disable commonName matching for certificates

Matching the commonName has been deprecated for
nearly 20 years, as it's a fallback path for
certificates that don't have a subjectAltName.

Disable the matching by default, but introduce an
enterprise policy that allows it to be enabled for
certificates that chain to local trust anchors.
This policy is similar to the SHA-1 deprecation
policy, and is named
EnableCommonNameFallbackForLocalAnchors.

For systems without enterprise policies (meaning
they aren't using SSLConfigManagerPref), the
default is to keep the insecure behaviour, which
is most compatible with legacy, but is not secure.

BUG=308330
Review-Url: https://codereview.chromium.org/2719273002
Cr-Commit-Position: refs/heads/master@{#454752}
Committed: https://chromium.googlesource.com/chromium/src/+/0f9bfb00c432d594504502728b8a1405a0ff2cf1

[Ryan Sleevi, 2017-02-28 02:16:57]

rsleevi@chromium.org changed reviewers:
+ atwilson@chromium.org, isherman@chromium.org, mattm@chromium.org

[Ryan Sleevi, 2017-02-28 02:16:58]

Drew: As discussed over e-mail, this introduces the enterprise policy with a 1
year sunset and explicit versions set. Let me know if you're happy with the
text, or feel free to punt to someone else since I see you're marked slow.

Ilya: histograms.xml review for the updated policy. I'm a little concerned that
the re-generated script updated the ID for 336. Should I be worried?

Matt: I'm getting this to you early while I add some additional tests. This
should be fairly easy to review plumbing, since it's like the SHA-1 change you
added. A few comments for you below.

https://codereview.chromium.org/2719273002/diff/1/net/cert/cert_verify_proc.cc
File net/cert/cert_verify_proc.cc (right):

https://codereview.chromium.org/2719273002/diff/1/net/cert/cert_verify_proc.c...
net/cert/cert_verify_proc.cc:493: }
Similarly, I'll be updating tests in CertVerifyProc to cover these permutations,
via a MockCertVerifyProc's VerifyInternal :)

https://codereview.chromium.org/2719273002/diff/1/net/cert/x509_certificate_u...
File net/cert/x509_certificate_unittest.cc (right):

https://codereview.chromium.org/2719273002/diff/1/net/cert/x509_certificate_u...
net/cert/x509_certificate_unittest.cc:1146: test_data.hostname, common_name,
dns_names, ip_addressses, true));
I'll be adding additional tests to cover these permutations.

https://codereview.chromium.org/2719273002/diff/1/net/spdy/spdy_session.cc
File net/spdy/spdy_session.cc (right):

https://codereview.chromium.org/2719273002/diff/1/net/spdy/spdy_session.cc#ne...
net/spdy/spdy_session.cc:693: if (!ssl_info.cert->VerifyNameMatch(new_hostname,
false))
We can reason that this is OK (to hardcode as false) because we only support a
single commonName in our parsing logic, so there's never a possibility for two
commonNames to match but the hostnames be different.

https://codereview.chromium.org/2719273002/diff/1/net/ssl/ssl_config_service.cc
File net/ssl/ssl_config_service.cc (right):

https://codereview.chromium.org/2719273002/diff/1/net/ssl/ssl_config_service....
net/ssl/ssl_config_service.cc:91: new_config.sha1_local_anchors_enabled) ||
I'm going to split this part out into a separate CL and request merging for it,
since it'd affect policy propagation in M57.

[Ilya Sherman, 2017-02-28 02:52:14]

histograms.xml lgtm

[Ilya Sherman, 2017-02-28 02:52:57]

On 2017/02/28 02:16:58, Ryan Sleevi (overloaded) wrote:
> Ilya: histograms.xml review for the updated policy. I'm a little concerned
that
> the re-generated script updated the ID for 336. Should I be worried?

AFAICT, the semantics of that bucket haven't changed, so it's probably ok.

[Ryan Sleevi, 2017-02-28 03:47:37]

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

[commit-bot: I haz the power, 2017-02-28 03:48:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-28 04:51:29]

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

[commit-bot: I haz the power, 2017-02-28 04:51:30]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[mattm, 2017-02-28 18:50:48]

https://codereview.chromium.org/2719273002/diff/1/net/cert/x509_certificate.cc
File net/cert/x509_certificate.cc (right):

https://codereview.chromium.org/2719273002/diff/1/net/cert/x509_certificate.c...
net/cert/x509_certificate.cc:525: if (allow_common_name_fallback &&
cert_san_ip_addrs.empty() &&
These cases are a bit different than the old behavior (Eg, it can now fallback
to matching an IP from common name even if the cert has dnsName SANs, or vice
versa. Before that wouldn't happen.)
(Oh, it looks like patchset 2 fixed hostname case below but there's still the
ipaddr case here.)

https://codereview.chromium.org/2719273002/diff/1/net/ssl/ssl_config_service.cc
File net/ssl/ssl_config_service.cc (right):

https://codereview.chromium.org/2719273002/diff/1/net/ssl/ssl_config_service....
net/ssl/ssl_config_service.cc:91: new_config.sha1_local_anchors_enabled) ||
On 2017/02/28 02:16:58, Ryan Sleevi (overloaded) wrote:
> I'm going to split this part out into a separate CL and request merging for
it,
> since it'd affect policy propagation in M57.

doh, thanks.

https://codereview.chromium.org/2719273002/diff/20001/net/cert/x509_certifica...
File net/cert/x509_certificate_unittest.cc (right):

https://codereview.chromium.org/2719273002/diff/20001/net/cert/x509_certifica...
net/cert/x509_certificate_unittest.cc:986: { false, "www.bath.org",
"www.bath.org", "", "20.30.40.50" },
Add a test for hostname is ipaddress, common_name is ipaddress, and san
dns_names are specified but san ip_addrs is empty.

[Ryan Sleevi, 2017-03-01 02:18:57]

Description was changed from

==========
Disable commonName matching for certificates

Matching the commonName has been deprecated for
nearly 20 years, as it's a fallback path for
certificates that don't have a subjectAltName.

Disable the matching by default, but introduce an
enterprise policy that allows it to be enabled for
certificates that chain to local trust anchors.
This policy is similar to the SHA-1 deprecation
policy, and is named
EnableCommonNameFallbackForLocalAnchors.

For systems without enterprise policies (meaning
they aren't using SSLConfigManagerPref), the
default is to keep the insecure behaviour, which
is most compatible with legacy, but is not secure.

Because it's dependent upon the trust anchor, make
the matching consistent by folding it into the base
CertVerifyProc rather than the platform-specific
derived classes. The platform-specific nature of
name matching was an artifact for when we used to
delegate to the OS, but we haven't for quite some
time. This ensures that the CertVerifyResult's
is_issued_by_known_root will always be populated
prior to performing name checking.

BUG=308330
==========

to

==========
Disable commonName matching for certificates

Matching the commonName has been deprecated for
nearly 20 years, as it's a fallback path for
certificates that don't have a subjectAltName.

Disable the matching by default, but introduce an
enterprise policy that allows it to be enabled for
certificates that chain to local trust anchors.
This policy is similar to the SHA-1 deprecation
policy, and is named
EnableCommonNameFallbackForLocalAnchors.

For systems without enterprise policies (meaning
they aren't using SSLConfigManagerPref), the
default is to keep the insecure behaviour, which
is most compatible with legacy, but is not secure.

BUG=308330
==========

[Ryan Sleevi, 2017-03-01 02:19:10]

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

[commit-bot: I haz the power, 2017-03-01 02:19:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ryan Sleevi, 2017-03-01 02:20:03]

Matt: Thanks for the attention to detail. I've rebased this on the CLs I split
out and landed, and updated some of the tests. I'm still shaking through all the
tests that might have relied on MockCertVerifyProc not doing name matching, and
working on regenerating the keychain to add to this CL, but I think it's ready
for another stab, modulo those issues.

[Ryan Sleevi, 2017-03-01 03:43:49]

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

[Ryan Sleevi, 2017-03-01 03:43:58]

The CQ bit was unchecked by rsleevi@chromium.org

[Ryan Sleevi, 2017-03-01 03:46:24]

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

[commit-bot: I haz the power, 2017-03-01 03:46:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-01 04:19:23]

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

[commit-bot: I haz the power, 2017-03-01 04:19:24]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ryan Sleevi, 2017-03-01 04:51:30]

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

[commit-bot: I haz the power, 2017-03-01 04:51:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-01 05:42:18]

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

[commit-bot: I haz the power, 2017-03-01 05:42:20]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Andrew T Wilson (Slow), 2017-03-01 16:54:04]

atwilson@chromium.org changed reviewers:
+ emaxx@chromium.org

[Andrew T Wilson (Slow), 2017-03-01 16:54:05]

+emaxx since I'm OOO this week

[mattm, 2017-03-01 23:56:48]

https://codereview.chromium.org/2719273002/diff/140001/net/cert/cert_verify_p...
File net/cert/cert_verify_proc_mac.cc (right):

https://codereview.chromium.org/2719273002/diff/140001/net/cert/cert_verify_p...
net/cert/cert_verify_proc_mac.cc:1002: verify_result->cert_status &=
~CERT_STATUS_COMMON_NAME_INVALID;
Is moving this down significant? (Not a big deal I guess, just curious why it
moved.)

https://codereview.chromium.org/2719273002/diff/140001/net/cert/cert_verify_p...
File net/cert/cert_verify_proc_unittest.cc (right):

https://codereview.chromium.org/2719273002/diff/140001/net/cert/cert_verify_p...
net/cert/cert_verify_proc_unittest.cc:1804: // Tests that commonName-fallback is
handled correctly:
The comment here mentions more cases than are actually tested (the cases with
subjectAltName being present aren't tested here).

https://codereview.chromium.org/2719273002/diff/140001/net/cert/x509_certific...
File net/cert/x509_certificate.h (right):

https://codereview.chromium.org/2719273002/diff/140001/net/cert/x509_certific...
net/cert/x509_certificate.h:290: // If |allow_common_name_fallback| is set to
true, then if no SANs are
nit: s/then/and/ ?

(Two "then" in the same sentence feels a bit weird.)

https://codereview.chromium.org/2719273002/diff/140001/net/data/ssl/certifica...
File net/data/ssl/certificates/aia-root.pem (right):

https://codereview.chromium.org/2719273002/diff/140001/net/data/ssl/certifica...
net/data/ssl/certificates/aia-root.pem:1: -----BEGIN CERTIFICATE-----
lost the pretty printed cert contents somehow..

https://codereview.chromium.org/2719273002/diff/140001/net/data/ssl/certifica...
File net/data/ssl/certificates/explicit-policy-chain.pem (right):

https://codereview.chromium.org/2719273002/diff/140001/net/data/ssl/certifica...
net/data/ssl/certificates/explicit-policy-chain.pem:159: -----BEGIN
CERTIFICATE-----
same

https://codereview.chromium.org/2719273002/diff/140001/net/ssl/ssl_config_ser...
File net/ssl/ssl_config_service.cc (right):

https://codereview.chromium.org/2719273002/diff/140001/net/ssl/ssl_config_ser...
net/ssl/ssl_config_service.cc:96: orig_config.require_ecdhe) !=
nit: maybe rename orig_config to old_config so it is the same length as
new_config and the lines wrap the same.

https://codereview.chromium.org/2719273002/diff/140001/net/ssl/ssl_config_ser...
File net/ssl/ssl_config_service_unittest.cc (right):

https://codereview.chromium.org/2719273002/diff/140001/net/ssl/ssl_config_ser...
net/ssl/ssl_config_service_unittest.cc:96:
mock_service->SetSSLConfig(initial_config);
I wonder if there should be a Mock::VerifyAndClearExpectations(&observer) call
after each of these sections?

[Ryan Sleevi, 2017-03-02 00:15:31]

https://codereview.chromium.org/2719273002/diff/140001/net/cert/cert_verify_p...
File net/cert/cert_verify_proc_unittest.cc (right):

https://codereview.chromium.org/2719273002/diff/140001/net/cert/cert_verify_p...
net/cert/cert_verify_proc_unittest.cc:1804: // Tests that commonName-fallback is
handled correctly:
On 2017/03/01 23:56:47, mattm wrote:
> The comment here mentions more cases than are actually tested (the cases with
> subjectAltName being present aren't tested here).

Yeah, I ended up moving them into the X509Certificate test to be more
comprehensive, so updated the description.

https://codereview.chromium.org/2719273002/diff/140001/net/ssl/ssl_config_ser...
File net/ssl/ssl_config_service.cc (right):

https://codereview.chromium.org/2719273002/diff/140001/net/ssl/ssl_config_ser...
net/ssl/ssl_config_service.cc:96: orig_config.require_ecdhe) !=
On 2017/03/01 23:56:47, mattm wrote:
> nit: maybe rename orig_config to old_config so it is the same length as
> new_config and the lines wrap the same.

Excellent suggestion!

https://codereview.chromium.org/2719273002/diff/140001/net/ssl/ssl_config_ser...
File net/ssl/ssl_config_service_unittest.cc (right):

https://codereview.chromium.org/2719273002/diff/140001/net/ssl/ssl_config_ser...
net/ssl/ssl_config_service_unittest.cc:96:
mock_service->SetSSLConfig(initial_config);
On 2017/03/01 23:56:47, mattm wrote:
> I wonder if there should be a Mock::VerifyAndClearExpectations(&observer) call
> after each of these sections?

We could, but I think we're fine as is, because the overall test would fail, and
it indicates where the expectation was set - which also indicates which
expectation failed.

[Ryan Sleevi, 2017-03-02 00:18:55]

https://codereview.chromium.org/2719273002/diff/140001/net/cert/cert_verify_p...
File net/cert/cert_verify_proc_mac.cc (right):

https://codereview.chromium.org/2719273002/diff/140001/net/cert/cert_verify_p...
net/cert/cert_verify_proc_mac.cc:1002: verify_result->cert_status &=
~CERT_STATUS_COMMON_NAME_INVALID;
On 2017/03/01 23:56:47, mattm wrote:
> Is moving this down significant? (Not a big deal I guess, just curious why it
> moved.)

Eh, it was an artifact of the previous build in which name checking was moved
here (because name checking depended on is_issued_by_known_root), but I split
that CL out, and forgot to move this part back. It has no material effect, but
moved it back for less file churn :)

[Ryan Sleevi, 2017-03-02 00:38:17]

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

[commit-bot: I haz the power, 2017-03-02 00:38:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mattm, 2017-03-02 01:56:47]

https://codereview.chromium.org/2719273002/diff/180001/components/policy/reso...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2719273002/diff/180001/components/policy/reso...
components/policy/resources/policy_templates.json:4856: 'supported_on':
['chrome.*:58-65', 'chrome_os:58-65', 'android:54-65'],
should android be 58-65 also?

[commit-bot: I haz the power, 2017-03-02 02:23:18]

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

[commit-bot: I haz the power, 2017-03-02 02:23:20]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[mattm, 2017-03-02 03:49:47]

lgtm, I'll leave that up to you

[Ryan Sleevi, 2017-03-02 06:11:09]

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

[commit-bot: I haz the power, 2017-03-02 06:12:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-02 07:19:27]

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

[commit-bot: I haz the power, 2017-03-02 07:19:28]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[emaxx, 2017-03-02 14:43:01]

LGTM with a nit

https://codereview.chromium.org/2719273002/diff/200001/components/policy/reso...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2719273002/diff/200001/components/policy/reso...
components/policy/resources/policy_templates.json:4869: If this policy is not
set, server certificates that lack a subjectAlternativeName extension containing
either a DNS name or IP address will not be trusted.''',
nit: Please add "or is set to false" after "If this policy is not set".

[davidben, 2017-03-03 02:24:27]

davidben@chromium.org changed reviewers:
+ davidben@chromium.org

[davidben, 2017-03-03 02:24:29]

components/ssl_config lgtm

[Ryan Sleevi, 2017-03-03 02:27:53]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2017-03-03 02:27:54]

The patchset sent to the CQ was uploaded after l-g-t-m from
isherman@chromium.org, mattm@chromium.org, emaxx@chromium.org
Link to the patchset: https://codereview.chromium.org/2719273002/#ps220001
(title: "emaxx feedback")

[commit-bot: I haz the power, 2017-03-03 02:28:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-03 03:59:03]

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

[commit-bot: I haz the power, 2017-03-03 03:59:06]

Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ryan Sleevi, 2017-03-03 04:00:03]

The CQ bit was checked by rsleevi@chromium.org

[commit-bot: I haz the power, 2017-03-03 04:00:21]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ryan Sleevi, 2017-03-03 04:03:37]

The CQ bit was unchecked by rsleevi@chromium.org

[Ryan Sleevi, 2017-03-03 04:48:05]

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

[commit-bot: I haz the power, 2017-03-03 04:48:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ryan Sleevi, 2017-03-03 04:49:42]

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

[Ryan Sleevi, 2017-03-03 04:49:44]

achuith: Can you approve the chrome/browser/chromeos/login change related to the
unit tests
david: Can you check the minica changes?

[davidben, 2017-03-03 06:14:57]

minica lgtm

https://codereview.chromium.org/2719273002/diff/260001/net/tools/testserver/m...
File net/tools/testserver/minica.py (right):

https://codereview.chromium.org/2719273002/diff/260001/net/tools/testserver/m...
net/tools/testserver/minica.py:255: asn1.Raw(asn1.TagAndLength(0x87,
len(ip_addr)) + ip_addr))
Nit: The indent here looks funny. The two for loops are indented two spaces too
many, I think.

[commit-bot: I haz the power, 2017-03-03 06:22:25]

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

[commit-bot: I haz the power, 2017-03-03 06:22:27]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ryan Sleevi, 2017-03-03 07:02:16]

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

[commit-bot: I haz the power, 2017-03-03 07:02:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-03 08:06:09]

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

[commit-bot: I haz the power, 2017-03-03 08:06:11]

Dry run: This issue passed the CQ dry run.

[achuithb, 2017-03-03 11:04:51]

On 2017/03/03 04:49:44, Ryan Sleevi (OOO until 3-7) wrote:
> achuith: Can you approve the chrome/browser/chromeos/login change related to
the
> unit tests

lgtm

[Ryan Sleevi, 2017-03-04 02:56:26]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2017-03-04 02:56:27]

The patchset sent to the CQ was uploaded after l-g-t-m from mattm@chromium.org,
isherman@chromium.org, emaxx@chromium.org, davidben@chromium.org
Link to the patchset: https://codereview.chromium.org/2719273002/#ps280001
(title: "More ChromeOS fixes")

[commit-bot: I haz the power, 2017-03-04 02:56:38]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-04 03:07:24]

CQ is committing da patch.

Bot data: {"patchset_id": 280001, "attempt_start_ts": 1488596186931950,
"parent_rev": "4736030020471fa4dca4eb223925cfdac92267df", "commit_rev":
"0f9bfb00c432d594504502728b8a1405a0ff2cf1"}

[commit-bot: I haz the power, 2017-03-04 03:08:06]

Description was changed from

==========
Disable commonName matching for certificates

Matching the commonName has been deprecated for
nearly 20 years, as it's a fallback path for
certificates that don't have a subjectAltName.

Disable the matching by default, but introduce an
enterprise policy that allows it to be enabled for
certificates that chain to local trust anchors.
This policy is similar to the SHA-1 deprecation
policy, and is named
EnableCommonNameFallbackForLocalAnchors.

For systems without enterprise policies (meaning
they aren't using SSLConfigManagerPref), the
default is to keep the insecure behaviour, which
is most compatible with legacy, but is not secure.

BUG=308330
==========

to

==========
Disable commonName matching for certificates

Matching the commonName has been deprecated for
nearly 20 years, as it's a fallback path for
certificates that don't have a subjectAltName.

Disable the matching by default, but introduce an
enterprise policy that allows it to be enabled for
certificates that chain to local trust anchors.
This policy is similar to the SHA-1 deprecation
policy, and is named
EnableCommonNameFallbackForLocalAnchors.

For systems without enterprise policies (meaning
they aren't using SSLConfigManagerPref), the
default is to keep the insecure behaviour, which
is most compatible with legacy, but is not secure.

BUG=308330

Review-Url: https://codereview.chromium.org/2719273002
Cr-Commit-Position: refs/heads/master@{#454752}
Committed:
https://chromium.googlesource.com/chromium/src/+/0f9bfb00c432d594504502728b8a...
==========

[commit-bot: I haz the power, 2017-03-04 03:08:09]

Committed patchset #15 (id:280001) as
https://chromium.googlesource.com/chromium/src/+/0f9bfb00c432d594504502728b8a...