This is an interesting bug. The autofill code is checking SSLStatus::security_style, which gives the content layer's simpler definition of security. We want to use SecurityLevel here, which takes Chrome's policies into account.

https://cs.chromium.org/chromium/src/chrome/browser/ui/autofill/chrome_autofill_client.cc?rcl=1475695348&l=351

zkoch, FYI this means that cc autofill will no longer work on any pages that Chrome deems DANGEROUS (with the red triangle in the omnibox). This includes pages flagged as malware, pages flagged as phishing, and SHA-1 2017 HTTPS pages. Let me know if you have an issue with that.

I think that seems reasonable. Something I don't have a good sense of is how common the SHA-1 thing is. If that's really common, I'd be a bit concerned. If it's a fringe case, I don't think we have any issues here.

I think it's a fringe case at this point. +sleevi do we have any recent page load stats that you could share?

Over a 28 day aggregation, we see less than 1% of main-frame loads. That number will hopefully be trending downward further now that the OS X alt-chain code has landed, and as soon as we can get the Windows strong-auth flag landed. Both of these will rule out 'false positives' (e.g. where SHA-2 chains exist, even if it's more expensive computationally and network wise to find them)

The histogram is Net.Certificate.SHA1.MainFrame  btw

rsleevi: is there a milestone you recommend I wait on, then (for the OSX alt-chain code and Windows strong-auth flag to go to stable)?

OS X has landed, I think Windows will be right after branch.

Re #7: OK, can you please update this bug when that's landed? I'll prep a CL to land afterwards.

Set the Windows bug as a blocker for this.

felt, I noticed that this IsContextSecure() method is meant to be kept in sync with the webview equivalent, AwAutofillClient::IsContextSecure(). AFAICT webview doesn't have any concept of SHA1 (or other Chrome-specific red-triangle-inducing conditions like malware).

Are we okay with these implementations diverging, such that ChromeAutofillClient::IsContextSecure() takes SHA1, etc. into account but AwAutofillClient::IsContextSecure() continues to base the decision off just url + cert errors?

More concretely, this would mean that credit card autofill would *not* be enabled in Chrome for pages that have SHA1 certificates, but it would be enabled in android webview for those same pages.

#11. I'm pretty sure we don't do Autofill in the traditional sense in AW [1] but rather Autocomplete, which means we won't suggest personal Autofill data and the secure checks are less important in my opinion. 

[1] PersonalDataManager returns your Autofill data such as addresses and Credit Cards, and here it's nulled:

autofill::PersonalDataManager* AwAutofillClient::GetPersonalDataManager() {
  return nullptr;
}

Removing HttpBad hotlist since it's unrelated.

wasn't able to get  to this, unassigning self

Is this bug still valid, now that Chrome 56+ aggressively block SHA1 chains as certificate errors? 

When I try the repro described, I get the "Automatic credit card filling is disabled because this form does not use a secure connection" notification and there's no attempt to autofill.

Deleted: M57.png 31.3 KB

	M57.png 31.3 KB View Download

Hmm, this appears to be related to https://codereview.chromium.org/2603823002, which has a stub bug at  Issue 678764 .

That CL creates "IsSecureContext()" by taking IsOriginSecure() and then tacking on a few checks.

Do we want a separate layer of security check apart from IsOriginSecure()? If Chrome is going to get this right, it will probably involve Enamel owning IsSecureContext() and being responsible for enforcement.

Per Comment 17 - are we good here?

I think we are more-or-less good when it comes to SHA-1, but we still have the problem that autofill does its own ad-hoc Not Secure check, which is not always going to match what's in the omnibox because it doesn't use security_state::SecurityLevel. Filed issue 701018 for that.