The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=11685 

------------------------------------------------------------------------
r11685 | wtc@chromium.org | 2009-03-13 16:35:38 -0700 (Fri, 13 Mar 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=11685&r2=11684

Log an error message when we don't find any
Proxy-Authenticate header that we support when establishing a
tunnel.

R=darin
BUG=8771
Review URL: http://codereview.chromium.org/42193
------------------------------------------------------------------------

Using Chromium build 11489, I am prompted for username and password when I visit an
HTTPS site or HTTP site. HTTP sites load correctly. For HTTPS sites I receive the
error as displayed in the attached screenshot. 

HTTPS error gmail.bmp 2.9 MB   Download

aaronfraser:

Thanks for the info and the screenshot.

Please download the latest build (11686 or later) from
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/

Run it with the command-line option --enable-logging.  This
will turn on the error logging I added in r11685 (see comment 1).

When you run chrome.exe with --enable-logging, it creates a
file named chrome_debug.log in the same directory as chrome.exe.
Please email that file to me after you reproduce the NTLM auth
failure with Squid for an HTTPS site.

Please review chrome_debug.log and delete or edit any sensitive
personal info before you send it to me.  You can also just
paste the contents of chrome_debug.log in this bug if the file
is small.  Thanks.

Build 11780. 

[5236:3424:1071373359:ERROR:http_network_transaction.cc(1433)] Can't perform auth to
the proxy http://10.10.10.27:3128/ when establishing a tunnel
[1068:5400:1071373546:ERROR:ipc_channel_win.cc(267)] pipe error: 109

Thanks for the error log message.  It shows that Squid
doesn't send any Proxy-Authenticate header along with the
second "407 Proxy Authentication Required" response, so
Google Chrome doesn't know how to proceed.  NTLM
authentication consists of two rounds of request/response.
The second 407 response should have a
"Proxy-Authenticate: NTLM ...", where "..." is the
authentication challenge (base64 encoded).

That's all I know.  If you maintain the Squid proxy,
can you check its error log to see if there is any
relevant message?

Thanks for the assistance. Unfortunately I don't maintain the Squid proxy. I'll have 
a chat to the IT guys and see if they can shed any light on the situation. 

So how come this works in Internet Explorer and Firefox? Is this some inherent 
security flaw in these browsers, or do they just handle it differently?

Internet Explorer and Firefox won't be able to proceed in
that situation either.  So Chrome must have sent a different
Proxy-Authorization request header to Squid to cause Squid
to respond differently.

If Firefox can do NTLM auth with your Squid proxy, could
you get the following Firefox preference settings?

1. Type "about:config" in Firefox's location bar.

2. Type "lm" in the Filter field.

3. Only three preferences should remain.  What are their values?

If the value of network.automatic-ntlm-auth.allow-proxies is true
(the default value), could you change it to false and try again?

Our NTLM code is copied from Firefox, but Firefox only uses the
code when network.automatic-ntlm-auth.allow-proxies is false.
(If network.automatic-ntlm-auth.allow-proxies is true, Firefox
uses a Windows system DLL to do NTLM.)

Here are the values in Firefox 3.1 Beta 2.
network.automatic.ntlm-auth.allow-proxies (default) true
network.automatic.ntlm-auth.trusted-uris (default) 
network.ntlm.send-lm-response (default) false

Changing the network.automatic.ntlm-auth.allow-proxies to false still loads gmail and
other https sites. 

Happens to me, too. Gmail doesn't work on my squid proxy server.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=14108 

------------------------------------------------------------------------
r14108 | wtc@chromium.org | 2009-04-21 09:48:21 -0700 (Tue, 21 Apr 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=14108&r2=14107
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.h?r1=14108&r2=14107

Log the "Proxy-Support: Session-Based-Authentication"
response header.

Log an INFO message whenever we receive an auth challenge.

R=eroman
BUG=8771
Review URL: http://codereview.chromium.org/67117
------------------------------------------------------------------------

aaronfraser and luca76:

Sorry about the delay in getting back to you.

Please download the latest build from
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/

Run it with the command-line options --enable-logging --log-level=0.
Note the --log-level=0 option, which will turn on the informational 
logging (INFO messages) I added in r14108 (see comment 11).

When you run chrome.exe with --enable-logging, it creates a
file named chrome_debug.log in the same directory as chrome.exe.
Please email that file to me after you reproduce the NTLM auth
failure with Squid for an HTTPS site.

Please review chrome_debug.log and delete or edit any sensitive
personal info before you send it to me.  Thanks.

wtc: thanks for following this up. 

Please find attached (note - still doesn't work for https sites).

Thanks.

chrome_debug 1.log 7.7 KB   Download

aaronfraser: thanks for the "chrome_debug 1.log" file.

The log seems to show that you entered your username/password
for the Squid proxy three or four times, and then the
Squid proxy responded with a "407 Proxy Authetication Required"
response without any Proxy-Authenticate header, which caused
Google Chrome to display the "Error 115 (net::ERR_PROXY_AUTH_REQUESTED)"
error page.

A "407 Proxy Authetication Required" response needs to come with
one or more Proxy-Authenticate headers to tell the browser which
authentication schemes (Basic, Digest, NTLM, etc.) the proxy
supports.  Without any Proxy-Authenticate header, Chrome doesn't
know how to handle the 407 response, so it has to display an error
page.

But I don't know what caused the Squid proxy to send a 407 response
without any Proxy-Authenticate header.  I also don't know why
your login attempt to the proxy failed...

Do you work near Mountain View, California by any chance?

I can confirm this issue: Dev channel Chrome 2.0.180.0 works over HTTP but not over HTTPS. Environment is a Windows XP laptop, NTLM authentication, 
and a Squid (I assume) HTTP proxy not under my control.

Tried with build 16467 and the parameters "--enable-logging --log-level=0", log file is attached. Note that the HTTPS connections mention something 
about blocked...

Note that in addition to the log file, some output to the console was generated:

[4712:4648:173518125:ERROR:http_network_transaction.cc(267)] Can't perform ntlm auth to the proxy http://proxy.FOO.de:3128/ over a non-keep-alive 
connection
[4712:4648:173518125:ERROR:http_network_transaction.cc(272)]   HTTP version is 1.0
[4712:4648:173518125:ERROR:http_network_transaction.cc(285)]   Has header Proxy-Connection: close
[4712:4648:173519828:ERROR:http_network_transaction.cc(267)] Can't perform ntlm auth to the proxy http://proxy.FOO.de:3128/ over a non-keep-alive 
connection
[4712:4648:173519828:ERROR:http_network_transaction.cc(272)]   HTTP version is 1.0
[4712:4648:173519828:ERROR:http_network_transaction.cc(285)]   Has header Proxy-Connection: close
[4712:4648:173526218:ERROR:http_network_transaction.cc(267)] Can't perform ntlm auth to the proxy http://proxy.FOO.de:3128/ over a non-keep-alive 
connection
[4712:4648:173526218:ERROR:http_network_transaction.cc(272)]   HTTP version is 1.0
[4712:4648:173526218:ERROR:http_network_transaction.cc(285)]   Has header Proxy-Connection: close
[4712:4648:173549593:ERROR:http_network_transaction.cc(267)] Can't perform ntlm auth to the proxy http://proxy.FOO.de:3128/ over a non-keep-alive 
connection
[4712:4648:173549593:ERROR:http_network_transaction.cc(272)]   HTTP version is 1.0
[4712:4648:173549593:ERROR:http_network_transaction.cc(285)]   Has header Proxy-Connection: close
[4712:4648:173562890:ERROR:http_network_transaction.cc(267)] Can't perform ntlm auth to the proxy http://proxy.FOO.de:3128/ over a non-keep-alive 
connection
[4712:4648:173562890:ERROR:http_network_transaction.cc(272)]   HTTP version is 1.0
[4712:4648:173562890:ERROR:http_network_transaction.cc(285)]   Has header Proxy-Connection: close

Firefox 3 and IE 6 and 7 work seamlessly.

chrome_debug.log 23.9 KB   Download

aggregat4: thanks a lot for your chrome_debug.log.  It shows that
for the HTTP CONNECT method (to set up a proxy tunnel for SSL),
your Squid proxy sent the NTLM challenge with a "Proxy-Connection: close"
response header.  So Chrome closed the connection, which broke
NTLM authentication because it requires the connection be kept
alive for the entire authentication sequence.

I did a web search and found a report of the same problem in
this email thread on the httpclient-users@hc.apache.org mailing list:

http://mail-archives.apache.org/mod_mbox/hc-httpclient-
users/200810.mbox/<1225312199.16300.48.camel@ubuntu>
http://www.mail-archive.com/httpclient-users@hc.apache.org/msg01366.html

Can you ask the administrator of your Squid proxy if he
knows how to fix this problem?

Why do Firefox and IE work seamlessly?  There are two possibilities.

1. Your Squid proxy offers both the "NTLM" and "Basic" authentication
schemes.  Perhaps Firefox or IE tries "Basic" after "NTLM" fails.

Please try using Firefox to connect to https://www.ibm.com/.  Does
the password dialog say "FOO-Proxy1"?  (I got the "FOO-Proxy1"
string from your chrome_debug.log.  It is the "realm" of your
Squid proxy for "Basic" auth.)  If the password dialog mentions
"FOO-Proxy1", that shows the "Basic" scheme is being used.

Darin, do you know if Firefox tries the next authentication scheme
when one scheme fails?

2. Perhaps Firefox or IE keeps the connection alive for NTLM,
ignoring the (incorrect) "Proxy-Connection: close" instruction
from the Squid proxy.

I attached a cleaned-up version of aggregat4's chrome_debug.log,
showing only the log messages relevant to this bug.

chrome_debug-aggregat4.log 15.4 KB   Download

Thanks for the quick response.

To your question about our Squid install: I would not be surprised if it is a broken version we have running but I'm 
going to have a hard time selling the bug report without some business critical use case that doesn't function. When it 
comes to Chrome they will tell me to use Firefox or IE instead. What would be useful if another program would show the 
same behaviour. 

Note that NTLMaps ( the Python free NTLM proxy) works flawlessly as well, I give my password once and then HTTP as well 
as HTTPS connections work without issue. Perhaps from the NTLMaps code it is easier to figure out what they do.

Regarding Firefox: I don't actually get a dialog box, it just resolves the page and seems to redirect to the HTTP site.

All,

  I manage an NTLM based squid (2.7) site.  I'm really wanting to see Chrome work
with it, but it does not.  (HTTP or HTTPS).

I'm willing to do some testing.  There's a lot of meat in this thread, but if I can
help, please let me know.

I also have a development environment so I can do some pretty good testing.

Thanks!

jagauthier: thanks for your offer to help.  Please follow the instructions
in comment 12.  Try both HTTP and HTTPS.

aggregat4: could you get the following Firefox preference setting?

1. Type "about:config" in Firefox's location bar.

2. Type "lm" in the Filter field.

3. Only three preferences should remain.  What's the value of
network.automatic-ntlm-auth.allow-proxies?

I understand the difficulty of fixing your Squid installation,
so don't worry about it.  Server software developers should know
about bugs in their code.  Client software developers often take
the path of least resistance and just change the client software
to cope.  Then the broken servers are unlikely to get fixed.
I'll try to submit a bug report to Squid's maintainers to fulfill
my civic duty.

I will implement a change to ignore the Proxy-Connection: close
header when NTLM authentication is in progress.

The value of network.automatic-ntlm-auth.allow-proxies is "true".

Regarding our local Squid proxy: I'm willing to put a change request in, I will try 
when I find some time to construct a test program in Java and see if it fails in a 
similar way. If I then had a concrete Squid version/changelog/bug report to point to 
on why it fails I can submit a local change request.

Having a workaround in Chrome would of course be extra sweet. 

Willing to try out any intermediate build to test.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=17673 

------------------------------------------------------------------------
r17673 | wtc@chromium.org | 2009-06-04 14:49:23 -0700 (Thu, 04 Jun 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=17673&r2=17672

For connection-based authentication schemes such as NTLM,
we keep the connection alive even if the server or proxy
tells us to close it.

R=eroman
BUG=http://crbug.com/8771
TEST=none
Review URL: http://codereview.chromium.org/119068
------------------------------------------------------------------------

jagauthier, aggregat4: I still haven't submitted a bug report to Squid.
Sorry about the delay.  I hope to do that tomorrow.

aggregat4: Please download the latest build (17673 or later) from
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/

I implemented the change I described at the end of comment 21.  Please
let me know if it fixes the problem for you.

I was going to submit a bug report to Squid, so I first searched
existing bug reports for this issue.

http://www.squid-cache.org/bugs/show_bug.cgi?id=928
http://www.squid-cache.org/bugs/show_bug.cgi?id=1447
http://www.squid-cache.org/bugs/show_bug.cgi?id=2022

The last bug report (2022) is the shortest and the most relevant to us.
Anyway, while reading through the bugs, I noticed one thing:

All of the clients affected by this bug (Chromium, Apache-HttpClient,
and Java) send HTTP/1.1 CONNECT requests *without* a
"Proxy-Connection: keep-alive" header

This, and the fact that Squid seems to be an HTTP/1.0 proxy, can explain
why Squid sends "Proxy-Connection: close" to these clients.

I will look up the HTTP CONNECT request headers that Firefox and IE send
when I get to work.  Darin, I remember we discussed this issue when I
implemented HTTP CONNECT, and it was my fault to omit the
"Proxy-Connection: keep-alive" header.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=17759 

------------------------------------------------------------------------
r17759 | wtc@chromium.org | 2009-06-05 12:44:09 -0700 (Fri, 05 Jun 2009) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=17759&r2=17758

Revert r17673, except for the code cleanup.

I will try the real fix (sending the "Proxy-Connection: keep-alive"
header with HTTP CONNECT requests) next.

R=eroman
BUG=http://crbug.com/8771
TEST=none
Review URL: http://codereview.chromium.org/114083
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=17761 

------------------------------------------------------------------------
r17761 | wtc@chromium.org | 2009-06-05 13:12:45 -0700 (Fri, 05 Jun 2009) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=17761&r2=17760
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=17761&r2=17760

Send the "Proxy-Connection: keep-alive" header with HTTP CONNECT
requests for compatibility with HTTP/1.0 proxies such as Squid.
This is required for NTLM authentication.

Fix some cpplint.py nits in http_network_transaction_unittest.cc.

R=eroman
BUG=http://crbug.com/8771
TEST=net_unittests passes all tests
Review URL: http://codereview.chromium.org/118316
------------------------------------------------------------------------

FYI: here are the CONNECT requires sent by Firefox and IE
when I visit https://bugzilla.mozilla.org/.

Firefox 3.0.10:

CONNECT bugzilla.mozilla.org:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) 
Gecko/2009042316 Firefox/3.0.10
Proxy-Connection: keep-alive
Host: bugzilla.mozilla.org

IE 7:

CONNECT bugzilla.mozilla.org:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 
2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322)
Proxy-Connection: Keep-Alive
Content-Length: 0
Host: bugzilla.mozilla.org
Pragma: no-cache

I also confirmed in an old bug report (in Google's internal bug database) that I 
said:

  According to https://bugzilla.mozilla.org/show_bug.cgi?id=201054,
  [the "Proxy-Connection: keep-alive" header] is required for NTLM
  authentication.
  ...
  I am not sure if we need "Proxy-Connection: keep-alive" before we
  support NTLM.

So I didn't have the foresight. :-(

I tested with a Squid proxy that identifies itself as "squid/2.6.STABLE18".

It always sends HTTP/1.0 response status lines.  For a successful CONNECT
request, it responds with just "HTTP/1.0 200 Connection established\r\n\r\n",
with no response headers.

This confirms that Squid 2.6 is an HTTP/1.0 proxy.

aaronfraser, luca76, and aggregat4:

Please download and test the following two builds from
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/

1. First, please test build 17762 or later.

This build sends the "Proxy-Connection: keep-alive" header
with HTTP CONNECT requests.  I hope this will fix ths
NTLM authentication problem with Squid for HTTPS sites.

2. Then, please test a build from 17673 to 17755, inclusive.

This build tries to keeps the connection alive even though
Squid sends us the "Proxy-Connection: close" response header
during NTLM authentication.  I'm not sure if this will work.

Thanks a lot for your help!

Hi wtc,

Thanks for all the work you've put into this.

1. I can confirm that Build 17762 works. I have tried for a number of https sites and
no problems. 
2. Build 17755 does not work 

So it looks like I can finally start using Google Chrome at work. Excellent.

Cheers. 

aaronfraser: Thanks a lot for all your help tracking down this bug.  I'm
sorry that it dragged on for three months.  I haven't been able to set up
NTLM auth on my own Squid proxy, which makes debugging very hard.

aggregat4: I'd still love to hear your test report of build 17762 or later.

I will now backport the fix (r17761) to the Beta and Stable channels.

wtc: thanks for all the work on tracking this down! Just got back from vacation, will
be back at work on Monday and will try it first thing. May get to it earlier through
the VPN from home but that may not be a clean test.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=18197 

------------------------------------------------------------------------
r18197 | wtc@chromium.org | 2009-06-11 13:58:55 -0700 (Thu, 11 Jun 2009) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/172/src/net/http/http_network_transaction.cc?r1=18197&r2=18196
   M http://src.chromium.org/viewvc/chrome/branches/172/src/net/http/http_network_transaction_unittest.cc?r1=18197&r2=18196

Backport r17761 from the trunk to the 172 branch.

Send the "Proxy-Connection: keep-alive" header with HTTP CONNECT
requests for compatibility with HTTP/1.0 proxies such as Squid.
This is required for NTLM authentication.

R=eroman,laforge
BUG=http://crbug.com/8771
TEST=net_unittests passes all tests
Review URL: http://codereview.chromium.org/123032
------------------------------------------------------------------------

Could not try with build 17762 because that crashed 5 seconds after startup, as did the 
next build. However, I tried with the latest one available (18192) and it worked fine.

I can now use Chrome for HTTP as well as HTTPS behind our Squid proxy with NTLM auth.

Thanks again wtc!

PS any idea when this will show up in the dev-channel?

aggregat4: thanks for verifying the fix.  This fix is already in the
current Dev channel release 3.0.187.0.

Could you also test a build between 17673 and 17755, inclusive?  Thanks.

(No comment was entered for this change.)