This is failing in the secure direction, so it's not a security bug. 

https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/nsUyV30S5C8 gives some context on this option. Have you verified that the rule in question is actually taking effect and that Chrome isn't actually loading https://127.0.0.1 which is serving a self-signed certificate?

Can you share a network log? https://dev.chromium.org/for-testers/providing-network-details

> https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/nsUyV30S5C8 gives some context on this option.

Thanks, I actually see exactly the same problem with `--host-resolver-rules`.

> Have you verified that the rule in question is actually taking effect and that Chrome isn't actually loading https://127.0.0.1 which is serving a self-signed certificate? And I don't have any local server running during this test.

Yep, if you just ignore certificate warning you'll go the right website. I even reduced test case to use `https://teller.spaco.io/api` that is pure JSON endpoint.

> Can you share a network log? https://dev.chromium.org/for-testers/providing-network-details

Yes, attached.

Deleted: chrome-net-export-log.json 146 KB

chrome-net-export-log.json 146 KB View Download

Ah, also when I run Chromium with these `--host-rules` I see that even some internal browser requests are failing (chrome-search://local-ntp/.... etc.). Does `MAP * 127.0.0.1` affect all requests even browser internal ones, can it be so that browser tries to access CA for some reason, but can't do so because of this too broad mapping?

RE #3: This is a good theory; it's possible/likely that we have requests affected by host-rules that may not have been in the past.

teller.spaco.io does not send a complete certificate chain and requires an extra download of the intermediate certificate "COMODO RSA Domain Validation Secure Server CA" in order to complete the chain. If that download fails, the ERR_CERT_AUTHORITY_INVALID will be seen.

Nice, thanks for the explanation!

Yes, everything works fine with the following rule --host-resolver-rules="MAP * 127.0.0.1, EXCLUDE teller.spaco.io, EXCLUDE *.comodoca.com".

So I've solved my issue, but I'm curious is it still a bug or intended behavior of Chromium (that is a bit difficult to debug)? Or maybe certificate deployed incorrectly and there way to correct it?

Thanks

Matt, Eric: I think there have been some changes around S13N to use more of the profile and less of the System URL Request context - does that sound right? If so, I wonder if these are symptoms of that; in this case, it sounds like both AIA fetching and extensions/internal requests (per Comment #3) may be affected.

I thought this only kicked in under the Network Service, but perhaps it was changed across the board?

Tested the issue on Win-10 using chrome reported version #63.0.3239.132 and on ubuntu 14.04 using chromium dev build #63.0.3239.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Run Chromium and navigated to https://teller.spaco.io;
2. Observed that certificate the website provides is valid and secure;
3. Closeed Chromium and re-run it with `--host-rules="MAP * 127.0.0.1, EXCLUDE teller.spaco.io"
4. Observed that chromium did not invoke and got ">" symbol on entering.
 
Note: It worked fine on Win-10 and no issues were observed.

aleh.zasypkin@ - Could you please check the screen cast and please let us know if anything missed from our end.

Thanks...!!

Deleted: 799722.ogv 5.5 MB

	799722.ogv 5.5 MB View Download

Hey,

I believe you just missed the closing quotation mark in --host-rules="MAP * 127.0.0.1, EXCLUDE teller.spaco.io" :)

Best,
Oleg

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I don't believe any requests have been moved from the system request context to the main request context, and even if they had, I don't see how that would change anything here.  I did refactor how the flag was hooked up back in M62 (https://chromium-review.googlesource.com/c/chromium/src/+/585637), but I haven't seen any reports before this one.  Experimentally, I can't reproduce (On Windows, at least).  https://teller.spaco.io correctly redirects me to https://spaco.online/.  If this is a Linux-specific issue, it's more likely related to cert validation, which has platform-specific bits.

Note that "host-rules" isn't a command line flag supported for use by end users.  We've kept it mostly because it's easier to keep it than to remove it, so I'm not sure we care enough to investigate.

@mmenke: On Linux/ChromeOS, we do the AIA fetching (using the URLRequestContext configured at https://cs.chromium.org/chromium/src/net/cert_net/nss_ocsp.h?rcl=e50425bed92b9a78403abfceeefe269f44cb92c7&l=34 ), so changes in how that's configured would manifest as described.

In this case, the issue is that the server doesn't send a complete chain, so we need to chase AIA, and those AIA chases are picking up the resolver rules. I wasn't sure if things had changed in that space (given Comment #3's remarks about "chrome-search://local-ntp/.... etc"). That said, this may have been preexisting, and as you mentioned, WAI.

I believe host-rules was been applied to all URLRqeuestContexts (Well, system, proxy, and the main one, at least), both before and after servicification changes.  It's implemented on a per-HttpNetworkSession basis rather than per-HostResolver, so one could imagine it not having been hooked up to the system (Or proxy) URLRequestContexts before, but I'm pretty sure it was always hooked up to all of them.

> Experimentally, I can't reproduce (On Windows, at least).  https://teller.spaco.io correctly redirects me to https://spaco.online/.  If this is a Linux-specific issue, it's more likely related to cert validation, which has platform-specific bits.

Yes, I can't reproduce this on Windows too. Just on Linux (not sure about MacOS).

> Note that "host-rules" isn't a command line flag supported for use by end users.  We've kept it mostly because it's easier to keep it than to remove it, so I'm not sure we care enough to investigate.

Is "host-resolver-rules" also not supported for use by end users? I see the same issue with this flag. Unfortunately both these flags are used in a wild (eg. by Electron, https://electronjs.org/docs/api/chrome-command-line-switches#--host-resolver-rulesrules).

host-resolver-rules is indeed supported.  The fact that you're seeing the same issue with it further indicates this is a cert validation issue.  It's hooked up in a much different manner, since it just modifies the result of DNS looks (host-rules replaces one host name with another just above the connection establishment layer, which is weird), and what requests it's hooked up to definitely has not changed.

Ok, then I'm groovy with closing this as WontFix/WAI if those hookups haven't changed.

Right now, Linux, ChromeOS, and Android use our AIA fetcher, which mean they'd all be impacted by resolver rules. In the future, this will hopefully apply to all platforms, so we'd be consistent in the "it doesn't work for incomplete chains"

So, just to summarize, what is/are the recommended solution(s) for my use case (Electron app that resolves all hosts to 127.0.0.1 except for the list of "trusted" HTTPS-enabled domains)?

I can think of only these two:

1. Make https://teller.spaco.io to provide full certificate chain (in case I control server);
2. Specifically exclude AIA/CRL/CA URLs from host-resolver-rules;

That sounds correct.

Could also try using an extension or a group policy blacklist, though they can't block some requests.  Blacklists only block web-initiated requets, I believe, and while extensions do see some internal Chrome requests, they don't see all of them.

Blacklist obviously can't redirect requests, but extensions can, though they work by rewriting URLs.