I created a netlog using content_shell. Could somebody from the net team please triage?

Deleted: netlog 34.6 KB

netlog 34.6 KB View Download

CC'ing davidben@: could you please take a look?

I am able to reproduce with tip of tree (a6a331af3e247c40a7aa360c0422db4ec4e5b275) build.  https://www.united.com/ual/en/us/ does not load in content_shell, but loads in chrome.  Netlog for content_shell shows failure with ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error, whereas chrome netlog does not contain this error at all.

Deleted: netlog-contentshell.json 58.6 KB

netlog-contentshell.json 58.6 KB View Download

Deleted: netlog-chrome.json 1.9 MB

netlog-chrome.json 1.9 MB View Download

This is working as intended.

The context of why:
1) Symantec certificates are not trusted unless they are logged via Certificate Transparency. This is a security policy from //net and communicated via https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html (see also: https://cs.chromium.org/chromium/src/net/data/ssl/symantec/README.md )

2) Embedders decide whether/how to support certificate transparency.
  a) By default, because it requires an update channel, embedders default to "distrust Symantec"
  b) If embedders wish, they can disable the enforcement of CT by providing a CTPolicyEnforcer to the URLRequestContext[Builder] that says to accept all certificates as compliant
  c) If embedders wish, they can indicate they support CT by initializing a CTVerifier (really: a MultiLogCTVerifier), for which they will provide up to date CT information

content_shell doesn't set any policy, so it falls under a.

rsleevi: Thank you for the explanation.  Since this is working as intended, I am closing it as WontFix.

I said WAI, but then I found the note that after further discussion, Eran was planning to change this :)

Marking it as assigned to Eran to update the shell content loader :)

Ryan, could you please jog my memory, which note are we talking about?
(Is that related to https://crbug.com/633614 ?)

For context, I jogged Eran's memory off-list, but Eran was going through all 'application' targets and places that setup HTTP loading stacks or SSL sockets to evaluate with their owners what the likely CT policy should be for those clients.

> c) If embedders wish, they can indicate they support CT by initializing a CTVerifier (really: a MultiLogCTVerifier), for which they will provide up to date CT information

As a downstream that needs to provide their own URLRequestContext, is it enough to add a call to AddLogs(net::ct::CreateLogVerifiersForKnownLogs())? I'm asking in particular because the lists in ct_known_logs_static-inc.h evolves over time and the changes done there might not reach my own project immediately. Is that OK or would I be better off just accepting all certificates as compliant?

In general, if you don't have an update mechanism that can reach the same population percentages in the same timeframe (6 weeks), and don't have the ability to inform users when they're woefully out of date, you've already got big security problems, so you're probably not "worse' off by disabling CT enforcement.

OK, let me just check if I understood the whole mechanism correctly.

Anyone actively doing CT verification must ensure Chromium's log list reaches their user base around the same time new Google Chrome releases are made, otherwise there are two risks:
1) Logs which have since been disqualified upstream will still be trusted.
2) Logs which have since been included upstream will not be trusted.

And all CT validation will start failing after 70 days (though this is no longer a fatal error).

Is that a fair assessment?

Correct.

And if you wish to disable CT, you can supply a DoNothingCTVerifier ( https://cs.chromium.org/chromium/src/net/cert/do_nothing_ct_verifier.h?rcl=0&l=14 ) and a CTPolicyEnforcer that says everything complies with your CT policies. The default CTPolicyEnforcer will otherwise enforce the security-relevant CT policies (requiring CT for EV certificates, and requiring CT as defined by the Chromium CT Policy)

Noted, thank you very much for the information.