Host rules collide with locally installed CA |
|||
Issue descriptionChrome Version: M56 OS: Ubuntu 16.04 What steps will reproduce the problem? (1) Setup an MITM proxy in reverse proxy mode at a known IP address for a certain host (2) Install the MITM proxy CA locally using certutil (3) Run chrome with a "--host-rules" CLI argument, mapping said host to the MITM proxy IP What is the expected result? TLS establishment should succeed. What happens instead? TLS establishment fails due to cert errors. Looks like when a host rule is set for a specific host, Chrome doesn't allow that host's cert to be signed by a local CA. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Mar 23 2017
I'm not sure what you mean. When configuring the MITM proxy's IP address in /etc/hosts, the setup is working fine. When Chrome gets the same mapping through host-rules, Chrome terminates the handshake due to cert errors.
,
Mar 23 2017
Can you provide a net-internals log and a more complete description of what you're doing?
,
Mar 23 2017
TL;DR: use --host-resolver-rules rather than --host-rules.
,
Mar 23 2017
Explanation for comment #4: --host-rules re-writes the URL seen by the lower layers of network stack. So in your situation it ends up being as if you had navigated to https://127.0.0.1/ (or whatever local address you remapped to). This is going to fail certificate verification because the cert would have to be for 127.0.0.1, not the name you remapped. --host-resolver-rules does what you want it to, namely it mocks out the DNS resolutions done by Chrome. So from Chrome's perspective it is still navigating to https://my-awesome-site.com/, only you overrode the IP address that it gets for my-awesome-site.com. The cetificate verification then is still for my-awesome-site.com.
,
Mar 23 2017
eroman@ - thank you, that makes perfect sense! |
|||
►
Sign in to add a comment |
|||
Comment 1 by rsleevi@chromium.org
, Mar 23 2017