Also see: https://www.chromium.org/Home/chromium-security/education/tls/sha-1
(and go/ltvrp)

Adding Drew & David in case there are any other labels to make sure we've got the right visibility.

Seems reasonable - do you have any ask from either of the enterprise teams for this?

atwilson: We know (from the MD5 deprecation and in general) enterprises aren't ready to migrate off SHA-1. See  Issue 120715   Issue 117834   Issue 124111  (Several of those reports were malware-caused, but several were enterprise proxy related). 

Basically, we want to get ahead of this by making sure the right enterprise escape hatch exists, so that we can safely change the defaults, while still ensuring enterprises migrate (this will not be a forever-policy, just a recognition that the internal PKI takes longer to migrate than the Web PKI)

Understood - my question was whether this work would be driven by you, or if there's tasks you'd like my/georges' team to tackle.

Oh! Sorry, I misunderstood. No specific ask, other than making sure we're comfortable with the policy name, language, and helping us with outreach/evangelism to make sure Enterprises know this is coming and how to set the policies to mitigate any disruption.

Friendly ping to get an update on this issue marked as Beta blocker.

Gentle Ping! Any update on this please.

Eric, Matt: Would either of you want to take a stab at this?

Largely, the issue here is one of plumbing. We don't really have a good design for non-policy-associated URLRequestContexts (such as it is), but for the [System/Profile] URLRequestContext, propagate some flag from policy down the layers to the net-stack, so that it can b pushed to the CertVerifier.

We don't really have the infrastructure for setting options on the CertVerifier. There's the CertVerifier::Request where we could hang the bool off of, but that means we'd be storing the bool on almost all cached/inflight requests, and I'm not sure that'd really be all that useful.

My other thinking was we could pass in to CertVerifier::CreateDefault (and friends) some sort of options structure that would then affect (immutably) how the created CertVerifier behaved.

A final option is we could just punt this, by having CertVerifier blindly accept SHA-1 if the root was not a known one, and then worry about haggling the design later.

Can't policies be updated during runtime? I think that would rule out setting it immutably during CertVerifier creation.

Also, does fetching/updating policies require making HTTPS requests that might hit one of these SHA1 servers? Seems like there could be a catch-22.

> Can't policies be updated during runtime?

They can, but not all policy flags support dynamic update, so it doesn't preclude it. For example, see Eric's WPAD change, which is setup early on during the IO Thread.

> Does fetching/updating policies require making HTTPS requests that might hit one of the SHA-1 servers?

Yes and no? On Windows/Mac/Linux/Android, the policies are pushed (via the appropriate methods; GPO, file system deployment, or MDM, AIUI), and so they'll be apriori available. That leaves ChromeOS/iOS, and while I'm not sure the situation on iOS, it arguably doesn't matter (because we'll be gated by the OS there anyways and can't do the verification). ChromeOS can fetch the policies, but as a design, ChromeOS doesn't let you MITM some aspects of the code, such as update engine, so you shouldn't run into this anyways.

So it "should" just be a matter of plumbing it down, although these are good questions that we should document.

The reason Andrew marked it RBB is if we want to turn off SHA-1 come Jan 1, we'll need some form of escape hatch. The ideal world is we fail-closed unless the policy is set, but as I mentioned in Comment #10, we could just punt and fail-open (that is, fail if SHA-1 & is_issued_by_known_root==false, otherwise, proceed) until we can work through the policies. My inclination is we should try to wire up the policy now, under the assumption a future CertVerifier would reject SHA-1, so at least we have an idea of what might need to change if that doesn't work.

Looked at it a little more. Any problem with plumbing it in CertVerifier::VerifyFlags? It looks like there are already some policy-controlled verification flags that get set that way (revocation checking and such), and it appears they get routed into the system request context properly.

Yeah, I suppose we could put it there, which makes it easier for copying over from the SSLConfig, and would avoid the bool overhead in the RequestParams by just smuggling it in the flags (the same, I suppose, as if we used explicit bools with packing, ala ":1"). It does feel slightly more error prone than setting it on the CertVerifier(), since we have more Verify() calls than CertVerifier constructor calls, but *shrug*

Are you thinking something like
VERIFY_ENABLE_SHA1_LOCAL_ANCHORS

(or something like that?)

This looks like OS-All but please correct me if I'm wrong.

Friendly reminder to always add an OS label to blockers, it's how the release team triages them.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9b3b296ad3c43aa058ba9b33126d2096f408c970

commit 9b3b296ad3c43aa058ba9b33126d2096f408c970
Author: mattm <mattm@chromium.org>
Date: Mon Aug 15 20:54:23 2016

Add enterprise policy to allow locally issued SHA-1 certificates.

BUG= 626432 

Review-Url: https://codereview.chromium.org/2239963002
Cr-Commit-Position: refs/heads/master@{#412041}

[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/chrome/browser/policy/configuration_policy_handler_list_factory.cc
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/chrome/test/data/policy/policy_test_cases.json
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/components/policy/resources/policy_templates.json
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/components/ssl_config/ssl_config_prefs.cc
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/components/ssl_config/ssl_config_prefs.h
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/components/ssl_config/ssl_config_service_manager_pref.cc
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/net/cert/cert_verifier.h
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/net/cert/cert_verify_proc.cc
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/net/ssl/ssl_config.cc
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/net/ssl/ssl_config.h
[modify] https://crrev.com/9b3b296ad3c43aa058ba9b33126d2096f408c970/tools/metrics/histograms/histograms.xml

Current automated tests are insufficient. Add unitttests and/or integration tests (e.g., using browsertest) to obviate ongoing manual testing.

Scott: The current policy, as wired, *does not* disable anything, so unittests and integration tests aren't possible - that is, the //net stack hasn't done the thing that makes this policy necessary, but we wanted to make sure the policy and documentation was in place *before* we begin making the changes (in M55)

mattm@: Can we get an update on the issue marked as Beta blocker.

Note: Probable date of M-54 beta launch is 2/3 weeks from now.