Regarding proxy authentication challenge when accessing HTTPS pages via an HTTP proxy.

[Pengyu Chen]

Hi everyone,

Greetings! I'm new to chromium-dev. Kindly point out if I do anything wrong (posting messages to inappropriate groups, using an incorrect message format, etc.).

0.

My investigation is based on commit e08dbd5 (tag 65.0.3300.0).

Unless otherwise specified, any "current", "latest", or unspecified version shall refer to this version.

1.

It's observed that Chromium currently has different behaviors when handling HTTP proxy authentication challenge for HTTP and HTTPS pages:

(Here I use proxy.crawlera.com:8010 as a sample proxy service provide, which shall give HTTP 407 status code upon unauthenticated requests)

A. When invoking this sample command `chromium --proxy-server=proxy.crawlera.com:8010 http://httpbin.org/get`, Chromium pops an "Authentication required" dialog.

B. When invoking this sample command `chromium --proxy-server=proxy.crawlera.com:8010 --ignore-certificaterrors https://httpbin.org/get`, Chromium says "This site can’t be reached" with an "ERR_UNEXPECTED_PROXY_AUTH" error.

2.

It's unexpected to me to see the outcome in example #1.B.

IMHO Chromium shall also prompt an authentication dialog.

Is there any specific reason not to prompt the authentication dialog?

3.

The ERR_UNEXPECTED_PROXY_AUTH check was introduced in commit 7a67a81536 (review URL: https://codereview.chromium.org/4575001).

That's merely an ad-hoc fix: make it ERR_UNEXPECTED_PROXY_AUTH to prevent browser crash (related bug: https://bugs.chromium.org/p/chromium/issues/detail?id=61701).

4.

The root cause of Chromium's mis-behaving on proxy authentication on tunneling (also the root cause of bug #61701 mentioned above) is believed to have been introduced in commit 8a1f331 (review URL: https://codereview.chromium.org/2101014).

In this commit, the following change has been applied to file net/http/http_network_transaction.cc:

```

@@ -1801,12 +1877,11 @@

 }

 

 bool HttpNetworkTransaction::ShouldApplyProxyAuth() const {

-  return (!using_ssl_ && proxy_info_.is_http()) || establishing_tunnel_;

+  return !using_ssl_ && proxy_info_.is_http();

 }

```

While this commit tried to make `establishing_tunnel_` part of the state machine, it incorrectly changed behavior of `ShouldApplyProxyAuth`:

- Before the change, it returns true for both HTTP and HTTPS (tunneling) requests over an HTTP proxy.

- After the change, it returns true for only HTTP requests.

And following changes of `ShouldApplyProxyAuth` all kept this behavior.

5.

Attached is my attempt to fix the issue.

After applying the patch, my local build works as expected.

Also, it passed existing unit tests.

6.

Kindly let me know if I made any mistake. Please don't hesitate to give your valuable opinions.

If you reckon the patch is okay, can you please add it to the review queue, or let me know whether is the right place to submit patches? (I'm sorry but I don't have committer access, nor am I sure where to post the patch: I suppose it's better to first ask in chromium-dev than opening an issue directly.)

Regards,

Pengyu

[Jakob Kummerow]

Please upload the patch for review, see the instructions at https://www.chromium.org/developers/contributing-code.

(I don't know anything about the code/behavior in question here.)

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/a1c2fba3-cfbd-4ad0-ad70-349110fda761%40chromium.org.

[Matt Menke]

Chrome's behavior looks correct.  We're trying to establish and tunnel through a proxy server.  We tell the proxy to connect to the destination server.  The proxy tells us it has connected.  We then establish an SSL connection to the desination server.  Then the destination server (Which is what we're now talking to, rather than the proxy) asks for *proxy* credentials.  We don't want to give the desination server credentials for the proxy, since if, say, we're talking to www.dest.com using www.proxy.com as a proxy, we don't want to send www.proxy.com's credentials to www.dest.com, so we fail the request.

It seems like there's a bug in the proxy here, if that's what it's doing.  I assume it's an SSL decrypting proxy, with a cert installed on the client machine for that to work.  It should be sending the auth challenge to Chrome before establishing a tunnel, so we know we're talking to a proxy.

[Pengyu Chen]

That makes sense, Matt.

Much appreciated.

[Pengyu Chen]

That makes sense, Matt.

Much appreciated.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---

You received this message because you are subscribed to a topic in the Google Groups "Chromium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-dev/r8u684cY3Rc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/0e1dd2c8-29d9-4902-900f-066dfc521b24%40chromium.org.

--

..for science, you monster.

[Aurish Hammad Hafeez]

Hi Peng-Yu Chen, 
So were you able to successfully run chromium --proxy-server=proxy.crawlera.com:8010 --ignore-certificaterrors https://httpbin.org/get?