command line parameter --proxy-server is ignored for CRL checks
Reported by
dravga...@gmail.com,
May 6 2018
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.183 Safari/537.36 Vivaldi/1.96.1147.36 Example URL: https://www.ing-diba.de Steps to reproduce the problem: 1. You need a local web proxy in your network for this test, something like Squid for example. 2. Your firewall needs to block direct Internet access. 3. Start the browser with --proxy-server=<proxy address>:<proxy port> 4. Try to access any site that uses EV certificates (e.g. banking sites) What is the expected behavior? The web page will load without delay. What went wrong? The web page doesn't load at all and instead presents a "ERR_TIMED_OUT" timeout error message. Constantly hitting F5 to reload may get the page to load after some time. The reason for this problem is that Chromium ignores the --proxy-server parameter and tries to reach the CRL directly which fails because the firewall blocks direct access to the Internet. Did this work before? No Chrome version: 65.0.3325.183 Channel: n/a OS Version: 10.0 Flash Version: Setting a Windows system wide proxy is often suggested as solution for this bug but that's not an option for various reasons. Instead please fix the bug. Thank you.
,
May 7 2018
,
May 7 2018
I believe on Windows, we defer to the system to fetch certs, which doesn't respect chrome settings, though I'm not positive of that. Could you provide a chrome://net-export log? https://dev.chromium.org/for-testers/providing-network-details
,
May 7 2018
Marking WontFix/WorkingAsIntended. As noted in comment #3, we presently interact with the OS for certificate verification, while Chrome uses its own proxy settings for general browsing. This means you need to ensure the OS proxy settings are configured appropriately.
,
May 17 2018
What exactly do you mean by "ensure the OS proxy settings are configured appropriately"? I configured the proxy for WinHTTP which means the OS can successfully communicate with the Internet and download Windows updates for example. Still, the CRL checks don't work with Chromium because the requests are sent directly. I found a little VB script that uses WinHTTP to fetch an URL. I used it to fetch "http://crl.entrust.net/level1m.crl" which is the CRL for "https://www.ing-diba.de". It works just fine so that also confirms that WinHTTP is configured correctly. So how does Chromium do the CRL checks? It is obviously not asking WinHTTP to fetch the CRL and it also doesn't do it on its own using the "--proxy-server" parameter.
,
May 17 2018
https://support.microsoft.com/en-us/help/2623724/description-of-the-cryptography-api-proxy-detection-mechanism-when-dow WinHTTP has many proxy configuration settings. https://windowsexplored.com/2013/11/03/configure-winhttp-for-proxy/
,
May 19 2018
Thank you for those links. They are a bit outdated but according to them the Crypto API should first check a system proxy that was configured by "netsh winhttp set proxy <proxy address>:<proxy port>" which is the case on my system. So I took a laptop with Windows 7 which I still had around and put it in my network. I started Chromium with exactly the same parameters and configured WinHTTP the same as on my working machine. Guess what - https://www.ing-diba.de loaded immediately. The issue must be in Windows 10 then. I'll try to figure that out... Btw. the description of the Crypto API mentioned that the application (in this case Chromium) can instruct the API to use a specific proxy. I would really prefer that because it would be consistent and allow the user to quickly switch settings for the browser only. In my opinion when a user starts Chromium with the "--proxy-server" parameter this proxy should be used across the board. I know that you disagree with me on this one but I still wanted to express my opinion. |
|||
►
Sign in to add a comment |
|||
Comment 1 by susan.boorgula@chromium.org
, May 6 2018